Re: Review My Program

[Fred van der Windt]

You don't really need any code in the loadmodule at all, it only needs to 
contain the table (preceded a header that contains things like the table 
length, row length or whatever you need. Than you can do:

WORKING-STORAGE SECTION.
01 FNC-PTR FUNCTION-POINTER.
01 PTR REDEFINES FNC-PTR POINTER.

LINKAGE SECTION.
01 TBL.
  03 TBL-HDR.
   :
   03 TBL-DAT.
  :

PROCEDURE DIVISION.
SET FNC-PTR TO ENTRY 'tablename'
SET ADDRESS OF TBL TO PTR

You can also use the SET TO ENTRY statement to dynamically load a table that is 
in a separate load module.

Fred!

Re: Elegant code to extract length+data fields? A small challenge.

[Fred van der Windt]

Here is a solution that works if we know we can access up to three bytes of 
memory after the last length field. That is, if we can always use Load to get 
the length field from memory:

L R1,(,R14)  R1  = Integer plus trailing junk
LHI   R15,4
S R15,0(,Rn) R15 = 4-length
SLL   R15,3  R15 = (4-length)*8
*Length 0 => 32
*Length 1 => 24
*Length 2 => 16
*Length 3 =>  8
*Length 4 =>  0
SRL   R1,(,R15)  R1  = Integer 
STR1,Local_integer

Task 2) is also taken care of: a zero-length length fields results in a zero 
integer (but not -1).
Task 3) is easily implemented: replace the SRL by an SRA.
Taks 4) wouldn't be that hard either: use Grande instructions.

Fred!

Re: ASSEMBLER-LIST Digest - 21 Mar 2015 to 22 Mar 2015 (#2015-35)

[Fred . van . der . Windt]

> Regular expressions is the most god-awful piece of clap-trap garbage I have 
> ever laid my eyes on.  Yeah for you PC programmers!  Groans of disbelief from 
> us mainframe programmers at the
 > obtuse, obfuscating gibberish that RE is and that we will be forced into 
 > learning.

We'll have to agree to disagree on that one. We have our own implementation of 
a library that does regular expressions and I use it a lot. I think regular 
expressions are a very valuable and versatile tool... But your reaction is not 
uncommon: just about every 'hardcore COBOL/mainframe programmer' reacts the 
same way when they see their first regular expression.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: SIMD instructions uses; was Re: LZRG??? ....

[Fred . van . der . Windt]

> On Mar 12, 2015, at 18:31, Gary Weinhold  wrote:
> 
> Tom Ross didn't explain it, but did say the compiler developer was quite 
> enthusiastic about it.
> So we have to write a COBOL program, get the new compiler to generate 
> the code, get a z13 and run z/XDC to see what the instruction actually does!
> 
> Not too likely this week, I suppose.

Sounds like a plan. :)

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: LZRG??? Does this mean that 56-bit addressing is "a thing"?

[Fred . van . der . Windt]

I too would find that interesting.

Fred!

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of John McKown
Sent: woensdag 11 maart 2015 15:50
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: LZRG??? Does this mean that 56-bit addressing is "a thing"?

Given some of the new instructions, such as LGZR, I wish IBM would publish a 
manual with a title like: "What were the architects thinking of? Explanation of 
the reasons behind the instructions in the z architecture". Some are obvious, 
like L, ST, A. But why a single instruction to do this? Is it _that_ often 
used? And POPCNT is another one. Why do I need to know the number of 1 bits in 
each individual byte in a GPR? Is it _that_ common a question in application or 
system code? I can see the use for LT vice L + LTR

--
He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: LZRG??? Does this mean that 56-bit addressing is "a thing"?

[Fred . van . der . Windt]

> Pages 7 to 8 of this presentation:
> https://share.confex.com/share/124/webprogram/Session16609.html
>
> Evidently the code with SIMD instructions is the equivalent of what the 
> millicode does for SRST, but I may have misinterpreted what was said.  
> Using the millicoded instruction is evidently less efficient because there is 
> transition time to get into millicode mode.
> 
> And I have no idea how it works.

That was quite interesting. I wasn't SRST in any way but a now I at least got 
some clue what one could do with these new instructions. I'm still puzzled by 
this by the way:

VGBM VRF26,0x0
VSUMB VRF25,VRF25,VRF26
VSUMQF VRF25,VRF25,VRF26

This would seem to count every space (counted in VRF25) twice instead of only 
once. I'm still missing something or maybe I don't quite get the description of 
VSUM...

Fred!

-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: LZRG??? Does this mean that 56-bit addressing is "a thing"?

[Fred . van . der . Windt]

> When Dan Greiner used to present new hardware instructions at SHARE, he used 
> to mention some had uses in micro/millicode.  He talked about instructions he 
> had personally pushed > for because he could see performance benefits by 
> using them in millicode.  Those of us attending couldn't think of any 
> practical uses.
>
>  From my understanding of a  COBOL compiler presentation at SHARE, they cited 
> performance benefits by using the new SIMD instructions to replace search 
> instructions (SRST?),
> because the SIMD instructions were what the millicode used to implement the 
> instruction.

Oh? I would love to see an example of how one can use one of those VECTOR FIND 
or VECTOR STRING RANGE COMPARE instructions to do something that approaches 
what SRST does. I must admit that I have no idea how that would work...

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: John Ehrman Assembler Book

[Fred . van . der . Windt]

Looks very impressive. I can't imagine how much work John put into this. 
Amazing.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: signoff

[Fred . van . der . Windt]

Sorry to see you go. Feels like the end of an era...

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Redesigning the Principles of Operation Manual

[Fred . van . der . Windt]

I think the PoP should be split in two documents. The instructions descriptions 
would form PoO Volume I, the other chapters PoO Volume II (or the other way 
around).  The 'other' chapters are fine just the way the are and a PDF seems a 
good way to distribute the information.

The description of the intructions contain u huge amount of highly structured 
information that is not very suited to a 'sequential' format like a PDF 
document. This thread mentioned a lot of like:

What ADD instructions do I have?
What exactly does TROT do?
What instructions does this particular facility contain?
What does the opcode 0FE0 do?

Every one represents a valid use case but none of them are answered 
particularly well or fast by the the PoO in it's current form. I would propose 
that the information would be split in a description of every individual 
instruction and a taxonomy of the various properties of instructions. This 
taxonomy would look something like this:

Function
+ Logical
+ + And
+ + Or
+ + Exclusive Or
+ Mathematical
+ + Addition
+ + Division
+ + Multiplication
+ + Square Root
+ + Subtraction

Operand Location
+ Immediate
+ Register
+ + Access
+ + Control
+ + Floating Point
+ + General
+ + + 32 bit
+ + + + High
+ + + + Low
+ + + 64 bit
+ Memory

Operand Size
+ Byte
+ Halfword
+ Fullword
+ Double word
+ Quad word

Instruction Size
+ 2 bytes
+ 4 bytes
+ 6 bytes

Facility
+ Execute Extensions
+ High Word
+ Long Displacement
Et cetera

The description of every individual instruction would be tagged with all the 
relevant terms form this taxonomy and stored in some kind of database. A user 
interface should allow one to navigate the taxonomy structure and filter on 
additional terms.

Creating doesn't need to be that hard: creating the taxonomy and the 
descriptions could be a group effort. The result could be stored in a note 
taking app that allows structures of tags. Unfortunately the default iOS Note 
taking app or Vesper (my note taking app of choice) don't support that. But I'm 
sure "there's an app for that'. But I'm not sure if that falls within the usage 
terms of the PoO...

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Redesigning the Principles of Operation Manual

[Fred . van . der . Windt]

 
>> format
>> does not work as a PDF (or similar format).
> 
> It does, if you print it. 

Ok, You're probably right but is "printing the pdf" really the common way to 
use the document..?
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Redesigning the Principles of Operation Manual

[Fred . van . der . Windt]

Could't agreement more: the two columns are a nightmare. They may have just 
fine in the printed edition 20 years ago but they are no good in an electronic 
version...

I'm puzzled by the strong reactions this thread evokes. To me it is so obvious 
that the current format does not work as a PDF (or similar format). The various 
suggestions and ideas just show that need some kind of dynamic, configurable 
format with several ways to locate and display the information (an app is an 
excellent idea). But It amazes me that there are actually people that think the 
current format is just fine and doesn't need any improvement...

Sent from my new iPad

> On Nov 14, 2014, at 18:44, Martin Packer  wrote:
> 
> Two column format is fine, literally, on paper. But for navigating as a 
> PDF it's a nightmare. GDDM manuals are similarly two-column and it drives 
> me nuts.
> 
> Cheers, Martin
> 
> Martin Packer,
> zChampion, Principal Systems Investigator,
> 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
> 
> 
> 
> From:   Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu>
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date:   14/11/2014 17:36
> Subject:Re: Redesigning the Principles of Operation Manual
> Sent by:IBM Mainframe Assembler List 
> 
> 
> 
> 
>> On Fri, 14 Nov 2014 09:03:59 -0500, Tony Thigpen wrote:
>> 
>> After thinking about this for a few days, the biggest 'complaint' I have
>> with the POP is the two columns. It makes me have to scroll up and down
>> just to read the end of the paragraph that started at the bottom of the
>> left side.
> 
> Some of us like it in two columns, some hate it. I happen to be in the 
> former group.
> 
>> The second issue is the way the "if 24bit, if 31 bit, if 64bit"
>> statements read.
> 
> For myself, I have no difficulty with the "for L, ... for LH, ..." kinds 
> of statements.
> 
>> Suggestions:
>> 1) Make each group of instructions (like ADD) start on a new page.
> 
> Not necessary, IMO
> 
>> 2) Use two columns for the instruction bit pictorials. Put 24/31 bit on
>> the left and 64 bit on the right.
> 
> Yuck.
> 
>> 3) Use a full width paragraph for things common to both 24/31 bit and 64
>> bit.
>> 4) Use the left column for 24/31 bit specifics and the right column for
>> 64 bit specifics. These groups are side by side for the same 'subject'.
>> If there is no 64 bit specifics, then leave a gap in the right side.
> 
> I really don't like this.
> 
>> 5) If possible, consider placing the simple examples directly after the
>> instructions.
> 
> Clutter. Please don't.
> 
> Clearly, there is no consensus here that any of the proposed changes are a 
> good idea.
> 
> -- 
> Tom Marchant
> 
> 
> 
> 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
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Redesigning the Principles of Operation Manual

[Fred . van . der . Windt]

> Start with ADD in Chapter 7, where 15 instructions are concisely compressed 
> into a meaningless hotchpotch of description.

That is an excellent point. The description would get a lot clearer if it just 
detailed one instruction. That could be a significant improvement. I'm sure IBM 
can come up with a mechanism to create such an end result without replicating 
every spec of information in the description of every instruction it applies 
to. That would make life easier for the authors and prevent errors in new 
versions.

I don't think I care much about the grouping of the instructions. Like others 
said: I mostly start in the index. I do think there is some sense in grouping 
instructions that require privileges to execute in a different chapter. I only 
write application level software and wouldn't want the control instructions 
mixed with the 'regular' instructions.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: How to assign length of generated instructions to macro variable?

[Fred . van . der . Windt]

> That is my intent. I'm asking for an address in (dynamically allocated) 
> storage (RX-type address) and a length that the macro is allowed to use at 
> that
 > address. I want to make sure the code the macro generates does not write 
 > beyond that area. If the area is to short, I want to inform the programmer, 
 > via
>  MNOTE about this fact and tell how much storage is needed. This MNOTE will 
> fail a successful assembly.

I'm still a bit puzzled by this discussion. I would implement this thing the 
other way around: the macro's just generate whatever amount of code is needed 
and at runtime I would simply allocate the required amount of memory to hold 
the generated code.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Convert to base64 help (Cross posted from IBM-Main)

[Fred . van . der . Windt]

The internet sites use an ASCII or UTF representation of the text string you 
enter, the mainframe uses EBCDIC. The base64 result will differ because the 
source string has a different binary content.

Sent from my iPhone

> On 8 aug. 2014, at 15:55, "Ward, Mike S"  wrote:
> 
> Hello all, I have found two assembler programs that are supposed to convert 
> data to base64. They do not seem to be working correctly. I have gone to two 
> sites on the internet that do online base64 conversions. I place a 32 byte 
> string of data into the input area and press the encode button. The data 
> returned does not match what the mainframe base64 assembler program returned. 
> I tried the data at 3 different internet sites. All three sited returned the 
> same results. I tried both assembler programs and used the same input string 
> that I used at the internet sites. The string generated on the mainframe does 
> not match what was returned at the internet sites. Ami missing something? Are 
> the programs broken? Any help appreciated. (Z/os V1.13)
> 
> TIA
> Mike.
> 
> ==
> This email, and any files transmitted with it, is confidential and intended 
> solely for the use of the individual or entity to which it is addressed. If 
> you have received this email in error, please notify the system manager. This 
> message contains confidential information and is intended only for the 
> individual named. If you are not the named addressee, you should not 
> disseminate, distribute or copy this e-mail. Please notify the sender 
> immediately by e-mail if you have received this message by mistake and delete 
> this e-mail from your system. If you are not the intended recipient, you are 
> notified that disclosing, copying, distributing or taking any action in 
> reliance on the contents of this information is strictly prohibited.
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: The rationale for using macros i

[Fred . van . der . Windt]

> Thus I agree completely with EJ. You are not overly concerned about someone 
> reading what command you entered (as they would likely be doing so only if 
> analyzing a dump or trying to figure out what command was actually
> entered that did something you did not appreciate).   But you should be 
> extremely concerned about subsequent readers of your code. And why make those 
> readers struggle over what REQUEST=C means?

Exactly. This is maybe the most important aspect in this issue. Code must be as 
explicit and readable as possible.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: The rationale for using macros i

[Fred . van . der . Windt]

> And in principle I much prefer the communication between invoker and macro te 
> be as explicit as possible. I see no value at all in
> allowing the programmer to omit one or two letters (or any amount) from the 
> value of a keyword. The time saved by not having to
> press those few keys cannot outweigh the readability and maintainability of 
> the code and the macro. 

> Furthermore it promotes the notion of 'Do what I mean, not what I say'. This 
> should be avoided at all cost in anything related to
> software development.

Or to sum it all up: what expectations can I possible have from a programmer 
that cannot be bothered to correctly spell a 'keyword=value' parameter?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: The rationale for using macros i

[Fred . van . der . Windt]

I completely agree with John Gilmore on the value and usefulness of macros. But 
his example is very unfortunate. Writing macros that accept the first unique 
part of a keyword value as valid input (as opposed to only the specified value) 
make maintaining such macros a pain.  When the macros functionality is extended 
and new values for a keyword are introduced it might not be possible to use the 
'appropriate' value. In this example:

> o sta, star, start, are recognized as instances of start,
> o sto, stop are recognized as instances of stop, and
> o s and st are not recognized as instances of either.

What should happen when we want to ass 'STATUS' as a new value? The current 
value 'STA' is an accepted abbreviation for 'START' and it cannot be removed 
because existing invokers use it. So 'STA' must still mean 'START' and 'STAT' 
could be an abbreviation for 'STATUS'? This certainly doesn't make life easier 
for the casual reader of software that encounters an invocation of the macro 
with 'keyword=STA'.

And in principle I much prefer the communication between invoker and macro te 
be as explicit as possible. I see no value at all in allowing the programmer to 
omit one or two letters (or any amount) from the value of a keyword. The time 
saved by not having to press those few keys cannot outweigh the readability and 
maintainability of the code and the macro. 

Furthermore it promotes the notion of 'Do what I mean, not what I say'. This 
should be avoided at all cost in anything related to software development.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Local Time conversion to/from UTC Time

[Fred . van . der . Windt]

Mine was confusing too, I think, because they do "Spring forward" too but their 
spring starts in September when we do our "Fall back"...

Sent from my iPhone

> On 7 jul. 2014, at 18:01, "Gary Weinhold"  wrote:
> 
> I believe I stated that in a confusing manner; what I meant was that 
> their Spring, when they go to DST, would be the same time as Fall in the 
> northern hemisphere.  I assume "Spring forward" would be in 
> September/October rather than March/April.
> 
> Gary
> 
>> On 2014-07-07 11:38, Paul Gilmartin wrote:
>>> On 2014-07-07, at 09:16, Gary Weinhold wrote:
>>> 
>>> Doesn't that depend on your hemisphere?
>> No.  Being in close communication with several Aussies, it's
>> evident to me that they switch from ST to DST in the Spring,
>> and from DST back to ST in the Fall, just as in the Northern
>> Hemisphere.
>> 
>> -- gil
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Local Time conversion to/from UTC Time

[Fred . van . der . Windt]

> Doesn't that depend on your hemisphere?
>
> Gary Weinhold

Yep: Nothern hemisphere: Spring forward, Fall back and the Southern hemisphere 
the other way around.

It is described in detail on (amongst other places) 
http://www.timeanddate.com/time/dst/.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: MVCL

[Fred van der Windt]

I did a few timing test with MVCOS when it was introduced but it was so 
shockingly slow that I never touched it again. Many times slower than any 
construction based on MVCL or an executed MVC.

Might be worth to have another look at it to see if it is faster these days.

Fred!

Sent from my iPhone

> On 21 mei 2014, at 16:34, "Robert Ngan"  wrote:
>
> For simple moves (i.e. non-padded) longer than 256 bytes and less than 4K,
> I've started using MVCOS with R00 set to zero.  It's said to be more
> expensive than MVC but does anyone know what the "break even" length is
> (approximately)?
> I'll probable continue using it regardless of the performance penalty since
> it's very simple to set up for a variable length move (for lengths longer
> than 4K, I'll stick with MVCL).
>
> I'd also be interested in a comparison between EX/MVC and MVCOS if anyone
> has that information.
>
> Robert Ngan
> CSC Financial Services Group
>
> IBM Mainframe Assembler List  wrote on
> 2014/05/20 17:38:06:
>
>> From: Gerhard Postpischil 
>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Date: 2014/05/21 02:49
>> Subject: Re: MVCL
>> Sent by: IBM Mainframe Assembler List 
>>
>>> On 5/20/2014 11:44 PM, Robin Vowels wrote:
>>> Sounds like overkill.
>>> MVC with EX would be simpler.
>>
>> It depends very much on the requirement. For example, building a longer
>> string from several different sources; MVCL sets the destination address
>> and residual length after completion, allowing for simple chaining of
>> multiple moves. While EX/MVC can accomplish the same thing, they require
>> a little more arithmetic.
>>
>> Gerhard Postpischil
>> Bradford, Vermont
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Carmine Cannatello's book

[Fred van der Windt]

Well, I guess your still just the first person even though you sent your address several times...Sent from my new iPadOn Jan 2, 2014, at 21:43, "Kurt LeBesco"  wrote:It is Jan 2 not Apr 1 right?On Jan 2, 2014 3:39 PM, "Kurt LeBesco"  wrote:AgainOn Jan 2, 2014 3:36 PM, "Kurt LeBesco"  wrote:Kurt LeBesco3 berncliff aveAlbany NY 12208On Jan 2, 2014 3:34 PM, "John Gilmore"  wrote:I going through my technical books I found that I have an extra,excellent-condition copy ofAdvanced assembler language and MVS interfaces, Wiley 1991.The fifth person who sends me his|her mailing address gets it postagefree.John Gilmore, Ashland, MA 01721 - USA-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: The Trainer's Friend Going Out Of Business Sale

[Fred van der Windt]

> After 38 years of creating and delivering training courses for IBM mainframe 
> (OS/360 through z/OS) application programmers, The Trainer's Friend, Inc. is 
> going out of business.

> It's been a merry ride, giving us the chance to meet and work with talented 
> and dedicated people in hundreds of companies, dozens of states, and ten 
> foreign countries. Thanks to all the people and
> companies we've worked with.

Hi Steve,

Sad to hear this. Thanks for everything you did for the Assembler community! I 
hope you'll continue to contribute to this list.

Regards,

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: XML Parser in HLASM?

[Fred van der Windt]

> Anything wrong with System XML? Perfectly feasible to use from HLASM.
> Cheers, Martin

Yes, and extremely efficient if you implement a String ID exit. But it's called 
*z/OS* XML System Services so it might not available under zUnix?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: wish? for two new instructions.

[Fred van der Windt]

> As we had been using the stack storage concept since the late 1970's, with a 
> suite of entry, exit, call and DSA macros, it was relatively easy to make all 
> of our assembler programs LE-compliant for our 1998 release.  For > most 
> assembler programmers, however, the thought of LE seems akin to entering the 
> den of the basilisk.

> David de Jongh

Almost all the assembler code I write is ‘just’ application code (as opposed to 
system exits, PC routines or whatever). It’s used in applications written in 
COBOL or PL/I. All of the assembler code is LE compliant (the LE entry and exit 
macros are used and R12 is reserved for the CAA) and I think this is actually 
an advantage: the entry and exit macros are very fast especially compared to 
alternatives where you must allocate a save area in every invocation. We also 
use LE heap storage whenever we need dynamic storage in the application. Fine 
as long as you don’t need to do special things like sharing memory between 
(instances of) applications and much faster than the STORAGE functions.

I don’t understand the reluctance towards LE in this particular scenario…

Fred!

-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: AMODE(24). How much is there?

[Fred van der Windt]

Way less than 10% for us.

Sent from my iPhone

On 19 apr. 2013, at 18:32, "Ed Jaffe"  wrote:

> I saw a discussionon IBM-MAINrecently about how many MVS TCBs was "too
> many" MVS TCBs in an address space.
>
> System control blocks like TCB, located in LSQA below 16MB, will likely
> never be moved above 16MB since it's still possible for a 24-bit program
> to load PSATOLD and reference GUPI fields in the TCB.
>
> This got me wondering about just how much AMODE(24) code is still out
> there--not only for z/OS but for other operating systems as well. Any
> ideas? Are most programs still 24-bit? Half of them? Ten percent or less?
>
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> http://www.phoenixsoftware.com/
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Good Performing Code (Was: Millicode Instructions)

[Fred van der Windt]

The two newest processors (z196 and zEC12) do out-of-order processing. Does 
that mean that we do not need to 'intermingle' instructions because the 
processor will do it for us?

Fred!

Sent from my new iPad

On Apr 18, 2013, at 17:05, "Phil Smith III"  wrote:

> John Ehrman wrote:
>> Performance concerns about individual instructions aren't worth much
>> effort. Things like operand alignment, data and instruction cache
>> retention, locality of reference, branch frequency etc. can have really
>> significant effects.
>
> For sure. But for the pathologically curious, if you have z/VM source, look
> at the main module for EXEC 2 (DMSEXE). It's full of lines like:
>  SLR   R0,R8  (DO IT WHILE R3 SETTLES)
>
> These must go back to what, 303x? 370 itself? Christopher J. Stephenson Sir
> Chris the EXECutor) wrote this code 30+ years ago, when that stuff DID
> matter.
>
> There were giants in those days...!
>
> ...phsiii
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Good Performing Code (Was: Millicode Instructions)

[Fred van der Windt]

> I understand also that unconditional branches are faster than conditional 
> branches.  So, which is faster:
>
> BNZ   LABEL  Branch most frequent
> or:
>  BZ*+8"fall through" most frequent
> B LABEL  Unconditional

It might seem naïve but I would assume that 1 branch (the first option) is 
always faster than 2 branches (the second option). The branch prediction in the 
CPU should figure out with execution path is most likely.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Happy Gilmore (was Length question)

[Fred van der Windt]

> Binyamin Dissen  http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel

Dissen Software, Bar & Grill?!

That *is* an unusual combination...

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Happy Gilmore (was Length question)

[Fred van der Windt]

> One commentlets keep our discussions, professional and technical.



Couldn't agree more. And it is also worth remembering that not all subscribers 
are native speakers. Posts that must be decoded with a dictionary aren't very 
helpful.



Fred!

-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Shifting The High Order Bits

[Fred van der Windt]

Combined with an And-instruction to clear the zones in the last one or two 
bytes (pending on the amount you want to shift)...

Sent from my new iPad

On Mar 28, 2013, at 21:54, "Fred van der Windt" 
 wrote:

> What about MVZ?
>
> Sent from my new iPad
>
> On Mar 28, 2013, at 21:23, "esst...@juno.com"  wrote:
>
>> Hi,
>>
>> does anyone have a routine, or event know an instruction
>> that would shift the high order bits of "n" bytes
>> either 8 bits of 4 bits to the left as a unit:
>> for example
>> X 'D48199838840F2F96bF2F0F1F340'
>>
>> D89884FF64
>> 41938029B20130
>>
>> then shift the high order bits to the left
>> 89884FF640
>> 41938029B20130
>>
>>
>> Paul D'Angelo
> -
> ATTENTION:
> The information in this electronic mail message is private and
> confidential, and only intended for the addressee. Should you
> receive this message by mistake, you are hereby notified that
> any disclosure, reproduction, distribution or use of this
> message is strictly prohibited. Please inform the sender by
> reply transmission and delete the message without copying or
> opening it.
>
> Messages and attachments are scanned for all viruses known.
> If this message contains password-protected attachments, the
> files have NOT been scanned for viruses by the ING mail domain.
> Always scan attachments before opening them.
> -
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Shifting The High Order Bits

[Fred van der Windt]

What about MVZ?

Sent from my new iPad

On Mar 28, 2013, at 21:23, "esst...@juno.com"  wrote:

> Hi,
>
> does anyone have a routine, or event know an instruction
> that would shift the high order bits of "n" bytes
> either 8 bits of 4 bits to the left as a unit:
> for example
> X 'D48199838840F2F96bF2F0F1F340'
>
> D89884FF64
> 41938029B20130
>
> then shift the high order bits to the left
> 89884FF640
> 41938029B20130
>
>
> Paul D'Angelo
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: SV: Instruction Lists/Counts.

[Fred van der Windt]

I wonder if the nuber of instructions of the cpu is very relevant to an 
audience that expecta a high level presentation about mainframes. Shouldn't you 
better focus on the specific merits of the platform instead of focusing on 
technical details?

Fred!

Sent from my new iPad

On Feb 15, 2013, at 23:02, "Thomas Berg"  wrote:

> A link:
> http://www.realworldtech.com/z196-mainframe/
>
>
>
> Regards
> Thomas Berg
> 
> Thomas Berg   Specialist   z/OS/IT Delivery   SWEDBANK AB (Publ)
>
>
>
>
>> -Ursprungligt meddelande-
>> Från: IBM Mainframe Assembler List [mailto:ASSEMBLER-
>> l...@listserv.uga.edu] För Gibney, Dave
>> Skickat: den 15 februari 2013 20:58
>> Till: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Ämne: Instruction Lists/Counts.
>>
>>  I am doing a high (very high) level presentation for my managers who
>> have no MF experience. I want a simple slide. Something like:
>> IBM architecture is not RISC, there are nnn instructions.
>> nnn Privileged
>> nnn General
>> nnn Decimal
>> nnn Cryptographic
>> etc.
>>
>> I've Googled and looked at some of the sites in the Dino ring including
>> hlasm.com and haven't found it. I don't find a nice set of counts in
>> Pops either.
>> Anyone know of such a list(s)
>>
>> Dave Gibney
>> Information Technology Services
>> Washington State University
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Model 2827 New Instructions

[Fred van der Windt]

Thanks, that worked!

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of David Bond
Sent: dinsdag 18 september 2012 23:40
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Model 2827 New Instructions

This worked for me:
http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr009.pdf

On Wed, 19 Sep 2012 00:33:40 +0300, Binyamin Dissen wrote:
>I am getting the same problem. Both firefox and IE. Even created a new ID.
>
>On Tue, 18 Sep 2012 14:05:53 -0400 "Farley, Peter x23353"
> wrote:
>
>:>Resourcelink access does not work for me.  Even after resetting my
password I get into a login loop and cannot download the PDF.  ISTR this has
happened to me before, but I never did find out why.
>:>
>:>Anyone have any idea when the PDF will be available on the bookserver
site?  Or even (shudder) the "Information Center"?
>:>
>:>Peter
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Model 2827 New Instructions

[Fred van der Windt]

> I had a similar logon problem several years ago. The counter intuitive
> solution was to remove the url from my trusted sites.

Hmm, my trusted site list is empty, so that can't be it. Does anybody have 
other suggestions?

Fred!


-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Model 2827 New Instructions

[Fred van der Windt]

Somehow I can't download the file. I have a registered IBM ID but can't login. 
I just keeps asking me to
enter my IBM ID and password without any hint about what is wrong. I requested 
a new password, but
that didn't seem to help either. The site told me I could continue as a 
registered user after I choose a
new password but I get in the same login-loop when I try to download the PoP.

And it all feels quite familiar. I think I had the exact same problem the last 
time a new version of the
PoP was published...

Fred!

Re: Base registers

[Fred van der Windt]

> All your bases are belong to us ?

For great justice.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: How good is the EX instruction?

[Fred van der Windt]

> I doubt that doing something little and then full is faster than doing it 
> full the first time
>
> If you observed major difference I do suspect that it is because the first 
> execution triggered a pagein (or a swap or a steal...whatever).

I did a very Q&D test and...

  J *+10
  CLC   0(1,R10),8(R10)
  EXRL  R1,*-6

...is about 25% faster than...

  CLC   0(1,R10),8(R10)
  EXRL  R1,*-6

So on a z196 the jump seems to be faster than the compare...

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: How good is the EX instruction?

[Fred van der Windt]

> Having the CLC near the EX helps for cache. I also like to assemble it
> in-line because the right USINGs apply. We noticed that it is
> attractive to run over the CLC (with the length byte 0 as assembled)
> and then EX behind your back to do the real thing. More attractive
> than branch over the target if the instruction lets you.

The USING-issue is a strong argument in favor of this: I juggle around USINGs a 
lot and it is a pain (and error-prone) to set up the same USINGs for a single 
instruction that needs to be EXecuted.

We use the HLASM Toolkit Structured Programming Macros which means that we 
can't easily insert an instruction 'after' a Jump instruction. Almost all the 
Jump instructions are generated by the SPM macros.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: How bad is the EX instruction?

[Fred van der Windt]

You're welcome. :-)

Fred!

Sent from my iPad

On Jan 12, 2012, at 16:33, "McKown, John"  wrote:

> As an aside, to whomever it was who recommended the TROO as a way to move 
> bytes from an input area to an output area, while testing for "unprintable" 
> bytes - thanks! It made my code much easier to write and understand. I was 
> going to use a TRT and an EX'd MVC in a loop. A TROO in a loop was super easy 
> to code.
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: 128-bit arithmetic

[Fred van der Windt]

> For 2) consideration of leap seconds is not just otiose, it is wrong.
> For 1) it is necessary.
>
> Consider the case of a pair of microsecond-scale time measurements on either 
> side of some midnight upon which a leap second is added to
> Gregorian time.  Would you really wish to have a value of the form v =
> 100+a µsec figure in a sequence  for which mean(v) was 10 µsec?

If you look at a (leap-second-aware) digital clock around midnight you will see:

23:59:58
23:59:59
23:59:60 (the cpu spins to prevent application activity)
00:00:00
00:00:01
etc

So the elapsed clocktime actually *is* 110 µsec. Most clocks are not aware 
of the leapsecond and will simply tick:

23:59:58
23:59:59
00:00:00
00:00:01
00:00:02

And are now one second ahead.

> More generally, think before you post.

...

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: 128-bit arithmetic

[Fred van der Windt]

>>No use of the TIME macro need or should figure in this operation.  Any
>>leap-second corrections would, for example, be washed out by the
>>subtraction:
>>
>>(T + L) - (t + L) = T + L - t - L = T - t.
>
>Only if the interval t-->T does not span the introduction of the Leap Second. 
>If t is in Year X and T is in Year X+1 then if the last minute
>of year X is 61 seconds long, your interval T-t will be off by one second.

Not really: not in seconds anyway. If the interval contains 10 'normal' seconds 
and the leapsecond the application will calculate a length of 11 seconds which 
is correct. Things might get a little bit weird if we try to convert the 
seconds back to minutes, hours and days that passed and attribute those to the 
actual (calender) date and time. Suppose your application starts running at 
00:00:00 on a day with a leap seconds and ends after exactly 86401 seconds. One 
might think that it ran for 24 hours, 0 minutes and 1 second and thus 'spanned' 
two days. But in fact it ran for 23 hours, 59 minutes and 60 seconds and ran 
*exactly* from start till end of one calender day.

It might not be a big thing for most applications but I'm sure there are 
circumstances where this makes a difference. The cpu-cpin during the 
leap-second probably prevents a lot of issues: it should prevent the scenario I 
just mentioned because an application cannot run till the end of the leap 
second: it would either end before the leap second or after the leap second on 
the next day at which point it's run did span two calender days.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: 128-bit arithmetic

[Fred van der Windt]

> No use of the TIME macro need or should figure in this operation.  Any 
> leap-second corrections would, for example, be washed out by the
> subtraction:
>
> (T + L) - (t + L) = T + L - t - L = T - t.
>
> Why all this pother?

And even if a leapsecond was inserted between the start- and endtime the result 
would still be correct and reflect the actual amount of (clock-) seconds that 
elapsed. I think IBM puts the CPUs in a 'spin' (or whatever it is called) 
during a leapsecond so your application certainly wasn't aware of that 
leapsecond.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Is a byte "printable"?

[Fred van der Windt]

> The first paragraph of your post comes very close to a description of a 
> (table-driven) Translate and Test, TRT, instruction.  Use one instead
> of a hand-coded loop.  It will be much faster and prettier.

Use TROO: TROO can scan the string, copy it to the destination buffer and stop 
at unprintable characters.

Fred!

-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: TYPECHECK(NOMAGNITUDE)

[Fred van der Windt]

> It seems that you want an option like AUTOTRUNC rather than a TYPECHECK 
> sub-option, which is intended to reduce confusion about what one might
> expect from different forms of immediate operand in some instructions.

Whatever the name, I want to be able to code for example:

  MVI   field,12345678

And end up with the truncated value x'4E' in 'field'. I agree this should 
controlled by some ACONTROL option so I it can be turned on before- and turned 
off after a particular source line or -block.

> Can you use something like this to store just the low-order 8 bits?
>
>LA  0,FQC7001_E_CREATE_DOCUMENT
>STC 0,FQC7001_OP+3

I could, but I don't want the executable code to 'suffer' (or just change) 
because of some syntax issue in the assembler. I know what code I want (a 
single MVI instruction) but need to find the best (most readable and 
maintainable) way to express it in HLASM. I feel we're missing an ACONTROL 
option to convey the message as clearly as possible to the assembler itself and 
future human readers.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: TYPECHECK(NOMAGNITUDE)

[Fred van der Windt]

> >ACONTROL TYPECHECK(NOMAGNITUDE)
>
> >As far as I understand this should instruct the assembler not to check
> >the magnitude of the immediate value
>
> "NOMAGNITUDE  Specifies that the assembler not perform magnitude validation 
> of signed immediate-data fields of machine instruction
> operands"
>
> MVI does not use a "signed immediate-data field".

That's what I figured too. But it is a bit disappointing (and strange) that 
this option would work for instructions like LHI but not for MVI or CLI

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: TYPECHECK(NOMAGNITUDE)

[Fred van der Windt]

Well,

It costs an extra two bytes in the instruction, two bytes in the literal pool 
and and additional memory access when the instruction is executed. Not exactly 
what I want. My current work-around is:

&FQC7001_E_CREATE_DOCUMENT_3 SETA  (FQC7001_E_CREATE_DOCUMENT AND 255)
  MVIFQC7001_OP+3,&FQC7001_E_CREATE_DOCUMENT_3

But that doesn't give me a fuzzy warm feeling either...

Fred!

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Martin Truebner
Sent: woensdag 28 december 2011 10:28
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: TYPECHECK(NOMAGNITUDE)

Fred,

for an average reader (like me) the following would be much more
readable:

 MVC   FQC7001_OP+3(1),=Y(FQC7001_E_CREATE_DOCUMENT)+1

okay- it costs an extra 2 bytes- but saved me reading your stm:

>> to assign the low byte of value that is larger than 255. This results
>> in an ASMA031E error message.

multiple times
--
Martin

Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at 
http://www.picapcpu.de
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

TYPECHECK(NOMAGNITUDE)

[Fred van der Windt]

I want to use MVI to assign the low byte of value that is larger than 255. This 
results in an ASMA031E error message:
** ASMA031E Invalid immediate or mask field
I tried to use ACONTROL to circumvent this issue:
PUSH  ACONTROL
ACONTROL TYPECHECK(NOMAGNITUDE)
MVI   FQC7001_OP+3,FQC7001_E_CREATE_DOCUMENT
POP   ACONTROL
As far as I understand this should instruct the assembler not to check the 
magnitude of the immediate value and I expected it to just generate the 
instruction with a truncated immediated value but instead I still get the same 
errormessage... What am I doing wrong? I'd appreciate every suggestion.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

PK87960

[Fred van der Windt]

Interesting suprise: the operational guys installed APAR PK87960 (they are 
preparing for z/OS 1.12). This APAR fixes the LOAD ON CONDITION mnemonics used 
by HLASM: all the mnemonics are now in line with the PoP.

I found I when I continued working on a new program that assembled just fine 
last week but now complains about an unknown instruction LROCH (it is now 
LOCRH). Unfortunately we allready have a number of programs in production that 
use the old names... Not much fun...

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: ASM Program to copy a file

[Fred van der Windt]

Yup,

But the last time I tried it MVCOS was (much) slower than an EXecuted MVC. 
Don't remember how it compared to a MVCL(E). But it xould help out if you might 
need to move more than 256 bytes but not more than 4096 bytes.

Fred!

Sent from my iPad

On Dec 10, 2011, at 21:01, "Steve Comstock"  wrote:

> On 12/10/2011 7:22 AM, Steve Comstock wrote:
>> On 12/10/2011 7:12 AM, Peter Relson wrote:
 I actually disdain using the
 linkage stack, for these reasons:
>>>
 BAKR / PR are included in Chapter 10 of the POO: Control
 Instructions, not Chapter 7, General Instructions; they
 are semiprivileged instructions
>>>
>>> I do not believe that that reason has merit.
>>
>> Hmmm. Are you advocating use of semiprivileged instructions
>> in application code then? Or only some of them? Which ones
>> are 'safe' or 'OK' to use in standard application programs?
>> Where does one draw the line?
>>
>
> Note: I just went and reviewed my course
> "z/OS Assembler Programming Part 4: z/Architecture and z/OS"
> and I see I included MVCOS, which also comes from Chapter 10.
>
> It looks to me, from the Pops, that if I am in problem
> state and the source and target addresses are valid for
> me, and the third operand has an integer between 0 and 4095
> and I zero out R0, then I have a variable length move that
> will work. No need for EX for variable length moves of length
> under 4K. Is that a fair assessment?
>
>
>>
>>>
 but I think the easy way is not always
 the best way, depending on circumstances
>>>
>>> No argument there.
>>>
 Save area chains may not be available or meaningful for
 debugging situations
>>>
>>> Available? Yes. Meaningful? Yes, but not as easily. And they only tell
>>> part of the
>>> story, with the other part being on the linkage stack.
>>>
>>> Peter Relson
>>> z/OS Core Technology Design
>>>
>>
>>
>> --
>>
>> Kind regards,
>>
>> -Steve Comstock
>> The Trainer's Friend, Inc.
>>
>> 303-355-2752
>> http://www.trainersfriend.com
>>
>> * To get a good Return on your Investment, first make an investment!
>> + Training your people is an excellent investment
>>
>> * Try our tool for calculating your Return On Investment
>> for training dollars at
>> http://www.trainersfriend.com/ROI/roi.html
>>
>
>
> --
>
> Kind regards,
>
> -Steve Comstock
> The Trainer's Friend, Inc.
>
> 303-355-2752
> http://www.trainersfriend.com
>
> * To get a good Return on your Investment, first make an investment!
>   + Training your people is an excellent investment
>
> * Try our tool for calculating your Return On Investment
> for training dollars at
>   http://www.trainersfriend.com/ROI/roi.html
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Edit instruction

[Fred van der Windt]

> The comfort or discomfort of the ASSEMBLER programmers is not significant in 
> this context, in my believe. Due to pipelining and cache issues,
> clever compilers will sooner or later outperform hand-written ASSEMBLER 
> programs.

The z196 is able to 'reorder' instructions for execution. Doesn't that diminish 
the impact of pipelining issues? Then it might help programmers to keep up with 
those clever compilers.

Did IBM publish information about the new features of the z196 processors in 
one of their Technical Journals?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Pipeline question

[Fred van der Windt]

> >> memory accesses are killing you.
>
> I do everything in less than 1K (plus TR-tables read) so

I remember a document that listed the latencies of the various z196 caches but 
I can't find it anymore. That should give us some idea of the cost of loading 
and storing data versus 'keeping it in the processor'.

Maybe somebody else knows if this information is available somewhere?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Pipeline question

[Fred van der Windt]

> I need 27 instructions (maybe more because of two JO after TROT) see end of 
> this post.
>
> But I am sure this code is faster than what was used before. The simple 
> relation 256 input bytes processed by 27 instructions to create 192 bytes -
> should speed up the whole precess by a factor (even if the TROT is slowing 
> stuff down).

I uploaded your code and tested it last weekend (lovely to have a the lpar all 
to yourself). It seems you where somewhat overly optimistic about the effects 
of 'using only 27 instructions to process 256 input bytes'. The code is more 
than 4 times slower than the original 'process 8 bytes using RISBG' variant.

I think the memory accesses are killing you. The original code does one TROO to 
convert the Base64 code to bytes with a 0...63 value and then every source byte 
is read once and every result byte is written once. Assuming a translate 
instruction does 2 reads and 1 write this results in 3 reads and 1.75 writes 
for every source byte. Your code accesses memory a lot more. I tried a quick 
tally:

Access
  MVC   INTER,TR1   256*RW
  TRINTER,INPUT 256*RRW
  MVC   INTER2,TR2  256*RW
  TRINTER2,INTER-1  256*RRW
  MVC   RESULT,INTER2   192*RW
  NCRESULT,TR31+2   192*RRW
  NCINTER2,TR31 192*RRW
  TRINTER2,TR32 256*RRW
  OCRESULT,INTER2   192*RRW
  LAR1,TR4
  LAR14,INTER
  LAR15,64
  LAR2,INTER+128
  TROT  R14,R2,164*RRRWW
  JO   *-4
  MVC   INTER2,TR6  256*RW
  TRINTER2,INTER-1  256*RRW
  OCRESULT,INTER2   256*RRW
  LAR1,TR5
  LAR14,INTER
  LAR15,64
  LAR2,INTER+192
  TROT  R14,R2,164*RRRWW
  JO   *-4
  MVC   INTER2,TR6-1256*RW
  TRINTER2,INTER-1  256*RRW
  OCRESULT,INTER2   192*RRW

6208 bytes read and 3776 bytes read to process 256 bytes means 24.25 reads and 
14.75 writes for every source byte (versus 3 reads and 1.75 writes).

We've seen simple 'rules of thumb' on writing faster code before in this group. 
Maybe we should add something about 'minimizing memory access':

1. Select the best algorithm
2. Minimize the number of memory accesses
3. Minimize the number of instructions

We also had something about using 'simple' versus 'complex' (millicoded) 
instructions but that also tends to invoke religious discussions about 
maintainability and such...

Fred!

-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Pipeline question

[Fred van der Windt]

Thanks,

I'll run it when I'm back at work and report back the results.

Fred!

Sent from my iPhone

On 13 aug. 2011, at 20:31, "Martin Trübner"  wrote:

> Fred,
>
> Code is in private mail
>
> --
> Martin
>
> Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
> more at http://www.picapcpu.de
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Pipeline question

[Fred van der Windt]

That is great. I'd like to give it a try and compare it to my other code. Could 
you mail me the complete source?

Thanks,

Fred!

Sent from my iPad

On Aug 12, 2011, at 17:51, "Martin Trübner"  wrote:

> Fred,
>
> I tested it - and it does work
>
> I need 27 instructions (maybe more because of two JO after TROT) see
> end of this post.
>
> But I am sure this code is faster than what was used before. The simple
> relation 256 input bytes processed by 27 instructions to create 192
> bytes - should speed up the whole precess by a factor (even if the
> TROT is slowing stuff down).
>
> The complete code (with translate-tables is here and I send it to
> whoever wants it).
>
>  MVC   INTER,TR1  prepare for rearrange to 14 23
>  TRINTER,INPUT
>  MVC   INTER2,TR2 prepare for spread
>  TRINTER2,INTER-1  spread to 1.4
>  MVC   RESULT,INTER2
>  NCRESULT,TR31+2  leave only 1..
>  NCINTER2,TR31leave only ..4
>  TRINTER2,TR32make it low order bits
>  OCRESULT,INTER2
> *   now we have first and last byte of a tripplet ready
> *now we take 64 bytes and make them 128
>  LAR1,TR4
>  LAR14,INTER
>  LAR15,64 Sending length
>  LAR2,INTER+128
> *  TROT  R14,R2,1   no stopping
>  DC X'B992',X'10',AL.4(R14,R2)  HELP HASM
>  JO   *-4
> *  rearrange 128 to 192
> *
>  MVC   INTER2,TR6
>  TRINTER2,INTER-1
> *
>  OCRESULT,INTER2
> *
> *now we take these 64 bytes and make them 128
>  LAR1,TR5
>  LAR14,INTER
>  LAR15,64  sending length
>  LAR2,INTER+192
> *  TROT  R14,R2,1   hardware know it but HASM don'T
>  DC X'B992',X'10',AL.4(R14,R2)  HELP HASM
>  JO   *-4
> *  rearrange128 to 192
> *
>  MVC   INTER2,TR6-1
>  TRINTER2,INTER-1
> *
>  OCRESULT,INTER2
>
> --
> Martin
>
> Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
> more at http://www.picapcpu.de
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Pipeline question

[Fred van der Windt]

Sounds intriguing!

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Martin Trübner
Sent: vrijdag 12 augustus 2011 11:47
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Pipeline question

Fred,

I am working on a solution that has 18 instructions for 252 input bytes 
would that be a gain?

--
Martin

Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at 
http://www.picapcpu.de
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Pipeline question

[Fred van der Windt]

Ah,

It seems I mangled the code a bit while copying it from the mainframe via 
notepad to Outlook (the asymmetry is a clue).  The correct code is:

DOFROM=(R2,)
  LMG   R0,R1,0(,R4)  Load 16 source bytes
  LAR4,16(,R4)
  RISBG R0,R0,06,11,02aaa0ccc0ddd0eee0fff0ggg0hhh0
  RISBG R1,R1,06,11,02aaa0ccc0ddd0eee0fff0ggg0hhh0
  RISBG R0,R0,12,17,04aaabbbc0ddd0eee0fff0ggg0hhh0
  RISBG R1,R1,12,17,04aaabbbc0ddd0eee0fff0ggg0hhh0
  RISBG R0,R0,18,23,06aaabbbcccdd0eee0fff0ggg0hhh0
  RISBG R1,R1,18,23,06aaabbbcccdd0eee0fff0ggg0hhh0
  RISBG R0,R0,24,29,08aaabbbcccdddeee0eee0fff0ggg0hhh0
  RISBG R1,R1,24,29,08aaabbbcccdddeee0eee0fff0ggg0hhh0
  RISBG R0,R0,30,35,10aaabbbcccdddeeefffe0fff0ggg0hhh0
  RISBG R1,R1,30,35,10aaabbbcccdddeeefffe0fff0ggg0hhh0
  RISBG R0,R0,36,41,12aaabbbcccdddeeefffgggff0ggg0hhh0
  RISBG R1,R1,36,41,12aaabbbcccdddeeefffgggff0ggg0hhh0
  RISBG R0,R0,42,47,14aaabbbcccdddeeefffggghhhggg0hhh0
  RISBG R1,R1,42,47,14aaabbbcccdddeeefffggghhhggg0hhh0
  STG   R0,0(R6)  Store 6 databytes
  STG   R1,6(R6)  Store 6 databytes
  LAR6,12(,R6)
ENDDO

> I would change the last two STG instructions - first R1 and then R0, because 
> R0 is the last reg used by a RISBG instruction.

That was taken into account in the (correct verion of) the code... But thanks 
for sharing your thoughts; I still don't understand what's going on here...

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Pipeline question

[Fred van der Windt]

> it took me some time to actualy get what you do (not BASE64 - but the
> RISBG)  my guess it is the RISBG itself which is very slow and apparently 
> not very pipeline-freindly (and I have no idea about the reasons).
>
> How about using this
>
>   LR1,0(,R4)   Load 4 source bytes
>   AHI  R4,4(,R4)   R4 past 4 source bytes
>   SLDL R0,6
>   SLL  R1,2
>   SLDL R0,6
>   SLL  R1,2
>   SLDL R0,6
>   SLL  R1,2
>   SLDL R0,6
>   STCM R0,B'0111',0(R6)  store 3 result bytes
>   AHI  R6,3
>
> I bet it is faster (and not only for the person looking at it).
>
> Not that I am against new stuff. I actualy have been reverting to z10 
> instructions in code written for the public (from z11 instructions).
> But there must be a gain for using them.

The code you suggest is almost identical to the code I replaced with the RISBG 
sequence:

  DOFROM=(R2,)
L R0,0(,R4)
LAR4,4(,R4)
SRDL  R0,8
SRL   R0,2
SRDL  R0,6
SRL   R0,2
SRDL  R0,6
SRL   R0,2
SRDL  R0,6
STCM  R1,B'1110',0(R6)
LAR6,3(,R6)
  ENDDO

I shifted right from R0 toward R1 and you're doing it the other way around but 
apart from that it is identical. And almost 2,5 times slower than the RISBG 
sequence! (I hope you're not a betting man). I guess the pipeline doesn't like 
this series of shift instructions either. It probably is just the fact that 
we're using 7 shift instructions to create 3 data bytes while the 7 RISBG 
instructions create 6 databytes (sounds like a factor 2) and we're only doing 
half the number of iterations (getting to almost 2,5?).

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Pipeline question

[Fred van der Windt]

This is a small part of code from a routine that decodes Base64 encoded data:
DOFROM=(R2,)
  LGR0,0(,R4) Load 8 source bytes
  LAR4,8(,R4) R4 past 8 source bytes
  RISBG R0,R0,06,11,02aaa0ccc0ddd0eee0fff0ggg0hhh0
  RISBG R0,R0,12,17,04aaabbbc0ddd0eee0fff0ggg0hhh0
  RISBG R0,R0,18,23,06aaabbbcccdd0eee0fff0ggg0hhh0
  RISBG R0,R0,24,29,08aaabbbcccdddeee0eee0fff0ggg0hhh0
  RISBG R0,R0,30,35,10aaabbbcccdddeeefffe0fff0ggg0hhh0
  RISBG R0,R0,36,41,12aaabbbcccdddeeefffgggff0ggg0hhh0
  RISBG R0,R0,42,47,14aaabbbcccdddeeefffggghhhggg0hhh0
  STG   R0,0(R6)  Store 6 databytes
  LAR6,6(,R6) R6 past 6 databytes
ENDDO
It takes 8 source bytes (already translated to contains 6 databits each), 
combines the six databits in each byte to create 6 databytes. The code contains 
a series of RISBG instructions that act on the same register. I figured it 
might be a lot faster to use two registers and interleave these operations:
DOFROM=(R2,)
  LMG   R0,R1,0(,R4)  Load 16 source bytes
  LAR4,16(,R4)
  RISBG R0,R0,06,11,02aaa0ccc0ddd0eee0fff0ggg0hhh0
  RISBG R1,R1,06,11,02aaa0ccc0ddd0eee0fff0ggg0hhh0
  RISBG R0,R0,12,17,04aaabbbc0ddd0eee0fff0ggg0hhh0
  RISBG R1,R1,12,17,04aaabbbc0ddd0eee0fff0ggg0hhh0
  RISBG R0,R0,18,23,06aaabbbcccdd0eee0fff0ggg0hhh0
  RISBG R1,R1,18,23,06aaabbbcccdd0eee0fff0ggg0hhh0
  RISBG R0,R0,24,29,08aaabbbcccdddeee0eee0fff0ggg0hhh0
  RISBG R1,R1,24,29,08aaabbbcccdddeee0eee0fff0ggg0hhh0
  RISBG R0,R0,30,35,10aaabbbcccdddeeefffe0fff0ggg0hhh0
  RISBG R1,R1,36,41,12aaabbbcccdddeeefffgggff0ggg0hhh0
  RISBG R0,R0,36,41,12aaabbbcccdddeeefffgggff0ggg0hhh0
  RISBG R1,R1,42,47,14aaabbbcccdddeeefffggghhhggg0hhh0
  RISBG R0,R0,42,47,14aaabbbcccdddeeefffggghhhggg0hhh0
  STG   R0,0(R6)  Store 6 databytes
  STG   R1,6(R6)  Store 6 databytes
  LAR6,12(,R6)
ENDDO
This requires only half the number of iterations and have less pipeline 
dependencies.

I was quite surprised to find out that the second version takes about as long 
as the first version (in some runs it even appears to be a liitle bit slower). 
Have I introduced some weird dependency between the loads or two stores or R0 
and R1 that negates everything? Any suggestions?

Fred!

-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: No Subject

[Fred van der Windt]

> Smarter phising, I'd guess. They now monitor the lists and determine whose id 
> to spoof. Then post with that id in order to make people think it is
> legit.

Not that much smarter: the "mannen-tassen" in the url is Dutch for "Man 
purses". Would anybody in this group be that interested in man purses? They 
should have had their John-clone post a link like "z12 new instruction list"!

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: philosopy question: use LE & HLASM?

[Fred van der Windt]

 >  I'd say it depends which part of USS you are intending to use and if you 
 > are intending linking to anything else.
 >  99% of the services can be straight assembler with no need for the 
 > aggravation of LE.
 >  We use it for message queues, shared memory and sockets without any 
 > problems.

What do you consider the "aggravation of LE"? Almost all the assembler code we 
write is LE-compliant and we consider LE a plus,..

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: philosopy question: use LE & HLASM?

[Fred van der Windt]

> On 7/6/2011 6:14 AM, John McKown wrote:
> > I am looking into writing an HLASM program on z/OS which will use UNIX
> > System Services. Should I just bite the bullet and make my routine LE?
>
> Well, I would, but perhaps that's just me.
>
> Calling the various UNIX System Services does not in general require LE, but 
> in an LE routine you also have access to things such as: direct
> invocation of C functions, callable LE services, and condition handlers.

And you can use the LE stack. Convenient and much faster than GETMAINing save- 
and work areas.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: CPU: ASSM vs ENTERPRISE COBOL

[Fred van der Windt]

> there is a real thing to discuss behind all those stories, IMHO. Due to 
> pipelining issues the proper order of instructions in the instruction stream
> becomes more important for modern hardware, and that is something that a 
> human coder cannot do as good as a good optimizing compiler can. So I
> believe that ASSEMBLER programming will stay for some amount of time, because 
> it is still important to manage those old application systems that are
> still around and working well, and it will continue to be important for some 
> systems level work, but for application programming and new
> development, the future is elsewhere.

I'm sure that an optimizing compiler can do an amazing job, but in this case it 
was Enterprise COBOL vs handcoded Assembler. I have a hard time believing that 
COBOL is faster than assembler in any scenario. Enterprise COBOL is our 'main' 
programming language and I haven't seen it perform any optimization worth 
mentioning (even with OPTIMIZE(FULL)). The current compiler still generates 
virtually the same code as it's predecessors did many versions ago.

Which means it is unforunate that Angel isn't able to post the code. Something 
must be awfully wrong with the assembler code if it is twice as slow as the 
Enterprise COBOL code...

Fred!

-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: CPU Serialnumber

[Fred van der Windt]

> We have a C function that creates UUIDs and it uses CSRSI.
> Works without problems. No ASSEMBLER needed, and no privileged instructions.

That is kind of funny: we want to replace the C function we currently use. It's 
the last bit of C we have and it doesn't even meet the UUID type I 
specifications. After a lot of detours it uses a random number instead of a MAC 
address or other unique machine identification. We'll replace it with an 
assembler routine that uses the serial number. I know, not quite the MAC 
address either but it will match the output of the TSO command UUIDGEN.

Fred!

-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: CPU Serialnumber

[Fred van der Windt]

> > I finished scanning the MVS Data Areas manuals for 'serial number' and 
> > found this:
> > PSA.PSAPCCAV -> PCCA
> > PCCA.PCCACPID contains the serial number Seems I found what I was looking 
> > for?
>
> Ah, but WHICH serial number? How many digits?
>
> Cheers, Martin

This field has a 12 digit CPU serial number. It is the same serial number as 
listed by e.g. TASID. Are there other serial numbers?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

CPU Serialnumber

[Fred van der Windt]

Is it possible to retrieve the serialnumber of the cpu the program is currently 
running on without the use of any privileged instructions?

Background: we want to generate UUIDs and need the clocktime (that's easy) and 
a unique identifier of the machine/CPU we're running on. The UUID algorithm 
normally uses the machine's MAC address but I have no idea how to retrieve that 
information either..

thanks,

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

CPU Serialnumber

[Fred van der Windt]

I finished scanning the MVS Data Areas manuals for 'serial number' and found 
this:
PSA.PSAPCCAV -> PCCA
PCCA.PCCACPID contains the serial number
Seems I found what I was looking for?

Fred!

-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: ASSEMBLER-LIST Digest - 19 Jan 2011 to 20 Jan 2011 (#2011-10)

[Fred van der Windt]

I guess you're one step ahead of most of the inflexible ones (young and old). 
They haven't made this observation yet. Many may never see it this way

Fred!

Sent from my iPad

On Jan 21, 2011, at 7:21, "John Walker"  wrote:

> IF the younguns HAVE to have it THEIR way or they won't play, then how can 
> they reasonably criticize us olduns for doing the very same thing?  Really.  
> If THEY are as inflexible as WE are, they do NOT have the right to criticize 
> US about inflexibility.  AND I know that is one of the primary complaints 
> from youngsters about us old farts, that we are 'inflexible', and yet here we 
> are seeing them do the thing they criticize US about.  Wake up everyone.
>
>
>
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: CFC and UPT

[Fred van der Windt]

Thanks to Walt, Bob and Tom for sending me the document. I appreciate it a lot.

Fred!

Sent from my iPad

On Dec 8, 2010, at 17:23, "Walt Farrell"  wrote:

> On Wed, 8 Dec 2010 04:26:47 -0500, Fred van der Windt
>  wrote:
>
>> On Mon, 9 Nov 2009 16:44:12 -0600, Michael Stack  wrote:
>>
>>> This may help: http://www.kcats.org/share/sort/slides/SortAst.pdf .  At
>> the same SHARE meeting, Tom Harper gave a complementary session on how to
>> implement the instructions.
>>>
>>> Mike
>>
>> Can somebody point me to that second presentation by Tom Harper? I vaguely
>> remember looking at it but can't find a link to the presentation anymore.
>
> Well, one place it's available is on the SHARE web site in the Proceedings
> section.
>
> http://proceedings.share.org/client_files/SHARE_in_San_Jose/S8122XX075002.pdf
>
> --
> Walt
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

CFC and UPT

[Fred van der Windt]

On Mon, 9 Nov 2009 16:44:12 -0600, Michael Stack  wrote:

>This may help: http://www.kcats.org/share/sort/slides/SortAst.pdf .  At
the same SHARE meeting, Tom Harper gave a complementary session on how to
implement the instructions.
>
>Mike

Can somebody point me to that second presentation by Tom Harper? I vaguely
remember looking at it but can't find a link to the presentation anymore.

Thanks,

Fred!

Re: SPM bug

[Fred van der Windt]

> Trouble comes when the SPMs are used by people who do not/cannot write macro 
> definitions.

Ah.

So if I code a macro invocation with parameters that do not meet the documented 
specification of that macro, but the macro ignores the incorrect parameters and 
uses the remaining parameters to generate some code  anyway without any mention 
of possible problems then I should not blame the macro but realise that I am 
not yet worthy to glance upon the macro facility.

I'll try.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: SPM bug

[Fred van der Windt]

> Ouch!  Otiose tokens should not be silently ignored.  Would:
>
>  DO UNTIL=((CR,R1,LT,R2),AND,(CR,R3,LT,R4))
>
>.. have produced the intended result?

Yes it does:

 DO UNTIL=((CR,R1,LT,R2),AND,(CR,R3,LT,R4))
+...@lb2  DC  0H
:
:
 ENDDO
+...@lb3   DC  0H
+CR  R1,R2
+BRC 11,#...@lb2
+CR  R3,R4
+BRC 11,#...@lb2
 BRR14

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: SPM bug

[Fred van der Windt]

> :>But why is this error not properly signalled?
>
> Because it wasn't coded to do it.

Anyway, I asked the 'right person in our organization' to report it to IBM as a 
bug in the HLASM Toolkit.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

SPM bug

[Fred van der Windt]

The syntax for AND and OR operators in the Strcutured Programming Macros is 
differs slightly between the UNTIL= and WHILE= options of the DO macro and 
every other SPM macro that supports conditions. This is not only very confusing 
but I was just bitten by the fact that the DO macro may silently accept an 
incorrect UNTIL= or WHILE= parameter and generate the wrong code.

For example:
DO UNTIL=(CR,R1,LT,R2),AND,(CR,R3,LT,R4)
  DOEXIT (CR,R5,LT,R6),AND,(CR,R7,LT,R8)
ENDDO
contains an incorrect DO macro but generates the following code without any 
warnings or errors:
 DO UNTIL=(CR,R1,LT,R2),AND,(CR,R3,LT,R4)
+...@lb2  DC  0H
   DOEXIT (CR,R5,LT,R6),AND,(CR,R7,LT,R8)
+CR  R5,R6
+BRC 11,#...@lb6
+CR  R7,R8
+   BRC 4,#...@lb1
+...@lb6  DC  0H
 ENDDO
+...@lb3   DC  0H
+CR  R1,R2
+BRC 11,#...@lb2
+...@lb1 DC0H
The DO macro seems to simply ignore the ",AND,(CR,R3,LT,R4)" and generates 
incomplete code (as far as the programmer's intentions are concerned). The 
correct syntax is:
DO UNTIL=(CR,R1,LT,R2,AND,CR,R3,LT,R4)
  DOEXIT (CR,R5,LT,R6),AND,(CR,R7,LT,R8)
ENDDO
But why is this error not properly signalled? Is it possible to change the 
macros to use one, consistent syntax (while maintaining backward compatability?

Fred!

-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Instruction Set Architecture (Subject: corrected)

[Fred van der Windt]

> It is not clear to me that the first is less error prone,
> especially when the program is modified later.  Either of
> these eats up another register to be used as an index.
> Unless the value of register 1 is set in close proximity to
> the LA, I would find the code to be confusing.  And if it is
> set immediately before the LA, you could also code:
>
>   LHI   R1,-4
>   LAR3,0(R1,R2)
>
> A better solution (IMO) is:
>
>   LRR3,R2
>   AHI   R3,-4

Or in this day and age:

  LAY   R3,-4(,R2)

Which does what it says: load R3 with the address in R2 minus 4 bytes.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Instruction Set Architecture

[Fred van der Windt]

> Boys! You stop fighting or I stop the car and put the
> assembler away until we get home.

He started!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Why do I get ASMA323W on LLILF?

[Fred van der Windt]

> > But you can only walk 4095 meters, can't you? Way short of
> the circumference of the globe.
> >
>
> but you  forget scale. Assume circumference is 4096 units and
> apply the above

In this case the circumference is 2147483648 steps. So 4095 steps isn't going 
to get me very far. Unless you would want to move 2147479552 (or more) steps 
backward.

Anyway; it seems everybody agrees on the fact that the base+index allows you to 
designate the starting point of an addressable window of 4096 bytes on a 
circular array of 2^31 bytes. The offset allows you to address any byte within 
that window.

And yes: it is possible to set up a combination of USINGs and register contents 
that allow you to assemble the instruction...

  LAR2,-4(R3)

It is clever, but not everybody thinks that it is wise. I for one, do not.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Instruction Set Architecture (Subject: corrected)

[Fred van der Windt]

Well

As demonstrated by this very discussion the first form will baffle just about 
any programmer. And the 'missing' comma is (at least with us) a bad habit as 
well.

>   LAR3,-4(R2)   Set R3 to 4 less than R2
>
> or:
>
>   LAR3,4092(R1,R2)  Set R3 to 4 less than R2
>

This wouldn't get my blessing either. The instruction is clear, but now the 
comment will lead to raised eyebrows. Instead code:

  LAR3,4092(R1,R2)  R3 := R2 - 4096 + 4092 (==> R2 - 4)

It is all very cute and clever but we shouldn't forget that this code has to be 
maintained. Any construct or notation that makes it harder for somebody else to 
understand what is going later on will cause problems one way or the other. In 
this particular case the original coder would probably have a hard time 
understanding what's happening if he revisited the code five years later

This applies to any language, not especially to HLASM, but some languages do 
seem to offer more opportunities to obfuscate function and mislead the 
unsuspecting reader.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Instruction Set Architecture (Subject: corrected)

[Fred van der Windt]

> Once my erroneous comma is removed, you can walk a lot further.
> Read John Ehrman's article, as cited earlier by Michael Stack:
>
>  http://www.kcats.org/csci/464/ho/usingtechnique.shtml

Not really. The offset will still and always allow you to walk 0-4095 bytes 
forward (from the base+index location). The original problem (and the examples 
in the link) just introduce an index register to offset the 4096 byte window 
relative to the base register. In a very obfuscated manner. I don't think 
anybody meant to say that an index register doesn't allow you to move the 
'window of addressability' anywhere you want.

The linked article already said it: "The point of these examples is not to 
recommend a particular practice, only to show how the assembler does its work; 
I hope they helped". I would 'gently correct' developers that dream up a code 
sequences like these in our shop.

Fred!

-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Why do I get ASMA323W on LLILF?

[Fred van der Windt]

> close, but no cigar. Addres arithmetic wraps.
> And if you wrap nearly all the way around, you effectively
> end up with an address slightly lower than the starting point.
> To my mind, this is *effectively* subtraction, even when
> *technicall* the processor performed addition.
>
> If you walk forward around the globe and stop 10 meters short
> of your starting point, the net result is the same as going
> back 10 meters. I'm sorry - it's as ugly (or beautiful) as it is.

But you can only walk 4095 meters, can't you? Way short of the circumference of 
the globe.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Instruction Set Architecture

[Fred van der Windt]

> I'm surprised that this would assemble.
>
>R:F  0  20  USING TEST5,R15
>21 *
>  4810 F0100001022  LHR1,=H'-4096'
>R:1 FFF000  23  USING -4096,R1
> 0004 4120 F004424  LAR2,*
> 0008 4130 2FFC   FC25  LAR3,-4(,R2)
>26 *
> 0010   27  LTORG
> 0010 F000  28=H'-4096'
>
> I don't understand why the instruction at line 25 assembles
> as 4130 2FFC.  As far as I can see, it should generate an error.
>
> Still, Robin is correct.  The base-displacement arithmetic is
> addition only.  The displacement is an unsigned value from 0
> to 4095.  So, if the program is loaded into location 1000 and
> executed, statement 24 would set register 2 to x'1004' and
> statement 25 would set register 3 to x'2000'.  That is, 1004+FFC.

You added the same USING I did to establish addressability of the literal pool. 
But that also seems to mess up the original problem because the weird R1 stuff 
isn't used anymnore. R2 is set to the address of the first LA instruction. R3 
is set to R2+FFC. Surely the R1 stuff is meant to do *something*?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Instruction Set Architecture

[Fred van der Windt]

>  LHR1,=H'-4096'
>  USING -4096,R1
>  LAR2,*
>  LAR3,-4(,R2)
>
> What does R3 now address?
>
> This caused a great deal of debate on this list several years
> ago.  Very few contributors got it right.

I would assume that the last LA would just add FFFC to the contents of R2. 
But the contents of R2 seem undefined; we need more information. I cheated and 
tried to assemble your code. It needs a base register to address the literal. 
It then uses that same register to assemble "LAR2,*" and all the R1 stuff 
isn't used anymore. If I change the code to...

  LHI   R1,-4096
  USING -4096,R1
  LAR2,*
  LAR3,-4(,R2)

...to get rid off the base register requirement it doesn't assemble anymore:

00 A718 F000   FFF00021LHI   R1,-4096
 R:1 FFF000  22USING -4096,R1
04  023LAR2,*
** ASMA307E No active USING for operand *
** ASMA435I Record 5 in NMBTEST.FQ.SRC(TEST) on volume: T0P007
08 4130 2FFC   FC24LAR3,-4(,R2)

So it all seems to depend on the active usings that aren't specified in the 
original question

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: The new POO (Props / ProP ) is available

[Fred van der Windt]

> I have up made the POP available at
> http://vse2pdf.com/coolstuff/sa22-7832-08.pdf
>
> Get it while you can because I will remove it if IBM tells me to.

Got it. Thanks.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: The new POO (Props / ProP ) is available

[Fred van der Windt]

>
> > My IBM ID has '@' sign and I can't download this pdf.
> > Maybe someone could upload this file on rapidshare?
> >
> I first registered when IBM ID was required to be email
> address, so naturally mine contains "@".  But with enough
> fumbling, hammering, and waiting, I was able to change my
> password (and change it back) and download the PoOp.
>
> So much for IBM's reputation for upward compatibility.

The 'Register' page only accepts email addresses as IBM-IDs. And it appears the 
PoP-page doesn't accept IBM-Ids *with* an '@'

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: The new POO (Props / ProP ) is available

[Fred van der Windt]

> but it can only be downloaded 10 times! I'm trying to set up
> one of their free premium accounts but that's not set yet
> (account has to be validated, but there are no instructions
> as to how to do that; maybe it's just a matter of waiting for
> the account information to propogate through their system);
> I'll post that information if I can get it set up.

Are these the instructions:

To download this file, the uploader either needs to upload the file again or 
first log in to his/her Premium Account and then upload the file again. The 
uploader just needs to click the delete link of the file to get further 
information.

..?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: The new POO (Props / ProP ) is available

[Fred van der Windt]

> I was able to download it last night. I didn't know about
> rapidshare; so I Googled and went to the sight and uploaded
> the doc; you can find it at:
>
>http://rapidshare.com/files/417022215/SA22-7832-08.pdf
>
>
> but it can only be downloaded 10 times! I'm trying to set up
> one of their free premium accounts but that's not set yet
> (account has to be validated, but there are no instructions
> as to how to do that; maybe it's just a matter of waiting for
> the account information to propogate through their system);
> I'll post that information if I can get it set up.
>
>
> Overall, a pretty cool site. I'll use it more. Thanks.

I can host it somewhere if that would help? Just mail it to me...

Groetz,

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: The new POO (Props / ProP ) is available

[Fred van der Windt]

> "What if I can't sign in with my current IBM ID?
>
> If your IBM ID is over 32 characters or contains an "@"
> symbol, it may not give you access to certain
> password-protected parts of ibm.com. This is a known,
> temporary condition, where a shorter, simpler IBM ID is
> required to access those areas properly. If you haven't
> already created a secondary IBM ID, return to the area where
> you had trouble signing in, and follow the 'Register' link
> from there to create one. Your subsequent attempts to sign in
> with this new IBM ID should succeed. Your original IBM ID and
> associated profile will be persist and will remain valid
> elsewhere around ibm.com"
>
> My IBM ID has '@' sign and I can't download this pdf.
> Maybe someone could upload this file on rapidshare?

I'm stuck in the same login-loop but this doesn't help me either. My IBM-ID is 
shorter than 32 characters by the way. I tried registering shorter names but 
that doesn't make a difference. Ca't login to download the PoP with any of 
them

What's up with this!?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: The new POO (Props / ProP ) is available

[Fred van der Windt]

> Subject: The new POO (Props / ProP ) is available
>
> http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d5
7819852571c500428f9a

Ah, at last. Time to find out what BRAFIX does8-)

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: number of new instructions

[Fred van der Windt]

> Another measure might be the thickness of a printed copy of
> PoO.  My S/360 edition is about 3/8" - 1/2" .  Does anyone
> have an actual printed copy of the current PoO?
>
> A page count from Acrobat would work, too. According to Acrobat:
>
> A22-6821-00 (no date - 1964?) has 168 pages.
>
> SA22-7832-07 (Feb 2009) has 1344 pages, exactly(!) eight
> times the original.
>
> At least this includes a (primitive) measure of the
> additional complexity, not just the instruction count.

I think that this is an excellent suggestion: it's a very 'graphical' way to 
demonstrate the difference, just what you need in a presentation.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Efficient Memory List

[Fred van der Windt]

> In your step #3 - if the list is kept in descending order
> [i.e. bottom-to-top] you can happily employ a single MVCL as
> it won't be overlapping.
> Of course, your binary search needs to know the order is descending.

I don't think the order has anything to do with it. The list can be stored in 
ascending or descending order but it must be stored at the end of the allocated 
area (free space at the start of the area) to be able to use one MVCL(E) to 
move existing entries down in memory and create an opening for a new item.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Efficient Memory List

[Fred van der Windt]

>  Store the list starting at the end of the memory area.
>  That way you can use one MVCL to move the list down
> 
> >>> Some CPU's [used to] raise 'overlap' CC on such MVCL's
> >>>
> >> That's not what I've read in the PoOp.  But was it
> different in the
> >> remote past?
> >
> > Maybe we are confusing MVCL and MVCLE? MVCL signals
> overlap, MVCLE always moves.
> >
> But a downward move never overlaps.

That's why I suggesting starting at the end of the area: you can open a slot 
with a single MVCL(E).

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Efficient Memory List

[Fred van der Windt]

> >> Store the list starting at the end of the memory area.
> >> That way you can use one MVCL to move the list down
> >>
> > Some CPU's [used to] raise 'overlap' CC on such MVCL's
> >
> That's not what I've read in the PoOp.  But was it different
> in the remote past?

Maybe we are confusing MVCL and MVCLE? MVCL signals overlap, MVCLE always moves.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Efficient Memory List

[Fred van der Windt]

> Your random input entry is a 32-bit number.  Two to the 32nd
> power is 4GB.  Let the 32-bit number represent the number of
> a bit in a contiguous string of bits that is 4 billion bits
> long.  The number of bytes to contain this array is 537 MB,
> which can easily be acquired above the bar or in a data
> space.  Find the byte address and bit offset within that byte
> that corresponds to the 32-bit input number.  Test the bit.
> If off, you have a new entry, so turn the bit on and process
> the new entry.  If on, you have a duplicate entry, so ignore
> the entry.

That must be the simplest solution and probably the fastest as well. But is 
there really no penalty for using so much storage? This table would probably 
use ten times as much storage as everything else in that address space. And 
what if dozens of address spaces (regions, batch jobs  or whatever) would 
invoke this module...?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Efficient Memory List

[Fred van der Windt]

> A hash Table, if there is a collision,  item is already here
> else it is not .

Or you have a second (ot third..) item that generates the same hash value.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Efficient Memory List

[Fred van der Windt]

> I'm not trying to be funny, but would an indexed vsam file be
> a plausible solution? Use the 4-byte code as the index.

Uh? I thought performance was an issue?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Efficient Memory List

[Fred van der Windt]

> 3) The binary search from step 1 indicates where the new
> entry should be inserted.  To add the entry to the list,
> individual entries are moved one at a time (to avoid
> overlapping moves) to open a spot in the list for the new entry.

Store the list starting at the end of the memory area. That way you can use one 
MVCL to move the list down (toward lower addresses) in memory to open the slot 
for a new entry. That should be much faster than moving every individual entry.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: LARL vs. Literal Alignment

[Fred van der Windt]

> 3. Best bet: avoid literals. I never code them. Bet you can
> always find a way around coding a literal; e.g., in the
> example above:
>
>   LARL  3,h23
>
> H23  dch'23'
>
> -Steve Comstock
> The Trainer's Friend, Inc.>

I am all for constants like...

SEC_HOUR DCF'3600'

But your example of a constant named 'H23' is something I would definitly not 
recommend. After 10 years of of updates the programs will be riddled with 
constants like:

H23   DCH'22'
NLG   DCC'EUR'

Use constants with an appropriate name if the literal isn't just a literal but 
has some functional meaning. Use literals for, well, literals.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: OP-code C8 3

[Fred van der Windt]

> > There is a millicode-only instruction with a mnemonic of
> MVCX.  It is
> > used by millicode for variable-length moves without the need for
> > EX+MVC.
> > (The
> > "Execute" instructions are really slow on modern machines.)
>  MVCX is
> > used by the millicode for MVCL and other instructions.  We
> know of the
> > MVCX mnemonic but not the op-code or the operand format.
>
> This seems like a good instruction for general use, any idea
> why it was not made available outside of millicode?

Didn't they give us 'MVCOS' to do that?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Mainframe Assembler Coding Contest - new problem #22

[Fred van der Windt]

> I've been wondering about the type of algorithms that this
> instruction was meant for. I know of some cases where you're
> interested in "any ones" but OC would do that. Or is emphasis
> on "string" as null-terminated sequence of bytes? But
> counting bits in a text string does not make much sense either...

Probably for managing bitmaps for memory- or file allocation tables?

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: zEnterprise - new PoPS?

[Fred van der Windt]

> I was reading the new Redpiece about the zEnterprise. It had
> a section which stated the z196 has 110 new instructions in
> the following catagories:

Youre refering to this bit from the Redpiece:

The z196 new instruction set architecture (ISA) includes 110 new instructions 
added to
improve compiled code efficiency:
  High-Word Facility (30 new instructions), with independent addressing to high 
word of 64
bit GPRs, and effectively provides compiler/ software with 16 additional 32 bit 
registers.
  Interlocked-Access Facility (12 new instructions), including interlocked 
(atomic) load, value
update and store operation in a single instruction, with immediate exploitation 
by Java.
  Load/Store-on-Condition Facility (6 new instructions), with load or store 
conditionally
executed based on condition code, achieving dramatic improvement in certain 
codes with
highly unpredictable branches.
  Distinct-Operands Facility (22 new instructions), with independent 
specification of result
register (different than either source register), reducing register value 
copying.
  Population-Count Facility (1 new instruction), which is a hardware 
implementation of bit
counting, achieving up to five times faster than prior software implementations.
  Integer to/from Floating point converts (39 new instructions).

Sounds interesting. But you have found the first description of new 
instructions I've heard of.

Fred!
-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-