Re: Does the z architecture have something like the SIMD instructions

[Ed Jaffe]

On 6/5/2020 12:15 PM, Seymour J Metz wrote:

The S/370 PoOps mentions the vector facility and says "Vector operations are 
described in the publication IBM System/370 Vector Operations, SA22-7125."

You can download it from 
http://bitsavers.org/pdf/ibm/370/vectorFacility/SA22-7125-3_Vector_Operations_Aug88.pdf


That old vector facility no longer exists on any modern mainframe.

There is a new one that is part of z/Architecture (starting with z13) 
and doesn't require extra hardware features.


It is FAST!


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Close MACRO in Z390

[Ed Jaffe]

On 5/16/2020 12:30 PM, Dave Wade wrote:

CLOSEMAC CLOSE (),MF=L



I would code it this way:


CLOSEMAC CLOSE (*-*),MF=L


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: *-*

[Ed Jaffe]

On 5/1/2020 8:13 AM, Gary Weinhold wrote:


The programmer at our place who used this convention once said that he 
learned much of his assembler programming style from JES2 source.  
Does anyone know if JES2 used the *-* convention? 


I just scanned SHASSRC on our system. It had 932 occurrences.

Scanning one of our product libraries I found 1,307 occurrences.

This is clearly a popular commenting technique...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: CL8''

[Ed Jaffe]

On 4/20/2020 9:40 AM, Paul Gilmartin wrote:



For such a case, I will always code:

DC CL8' '
  

Does that truncate properly, but quietly if:
o  is 8 bytes?
o  is 9 bytes?  (Should warn.)


Your "should warn" above is an incorrect assertion.

DC CL8'12345678901234567890' is perfectly legal and should *NOT* warn 
(unless some new warning option was added to HLASM that I missed).


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: CL8''

[Ed Jaffe]

On 4/19/2020 11:24 PM, Windt, W.K.F. van der (Fred) wrote:

DCCL8''


For such a case, I will always code:

DC CL8' '


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Does S0C5 still exist ?

[Ed Jaffe]

On 1/30/2020 12:42 PM, Keith Moe wrote:

A big disadvantage of SPIE/ESPIE is that it cannot be used in supervisor state. 
So you have to use ESTAE even if you know that you want to quickly recover with 
no dump, LOGREC, etc., from PIC-4/10/11 (such as when chasing system control 
blocks unlocked) or to catch arithmetic errors (divide by zero and the like) 
and continue on.



YES!


And how do you pronounce SPIE: SPY or SPEE?



I have always heard it pronounced SPY.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: BASR to AMODE 64

[Ed Jaffe]

On 12/3/2019 11:07 AM, Paul Gilmartin wrote:


Are cross-CSECT relative branches supported?  That feels like an
invitation to disaster: errors that can not be detected before
execution.



They have been supported since z/OS 1.7 or 1.8. Very handy to have!!!


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: BASR to AMODE 64 (Baseless code)

[Ed Jaffe]

On 12/2/2019 12:02 PM, Tom Marchant wrote:


Locating your constants at the beginning of the program allows
you to do that without sacrificing a register.



Prezactly! That's what we do (using LOCTRs)...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: BASR to AMODE 64 (Baseless code)

[Ed Jaffe]

On 12/2/2019 12:02 PM, Tom Marchant wrote:

Locating your constants at the beginning of the program allows
you to do that without sacrificing a register.



Prezactly! That's what we do (using LOCTRs)...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: BASR to AMODE 64

[Ed Jaffe]

On 12/2/2019 7:58 AM, Kerry Liles wrote:

Or

 LR  12,15
 USING entrypointname,12



And, of course, R15 is not even loaded with the entry point address for 
programs given control in AMODE(64) :-\


These days, one is expected to issue LARL/USING to your program 
constants. There is generally no need whatever for base register 
coverage of the code.



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Where do I find more info about new z15 instruction SORTL listed in Sept. APAR but not in POP

[Ed Jaffe]

On 12/1/2019 5:59 AM, Don Higgins wrote:

All

Where do I find more info about new z15 instruction SORTL listed in Sept. APAR 
but not in POP



I asked IBM about this pre-GA and was told that the doc was 
*deliberately* left out of PoOp because there were not yet any 
exploiters! WTF? How can anyone exploit something that isn't documented? 
My "push back" on that was left unanswered... :-\


Thinking it through on my own, I came to realize IBM has deliberately 
decided *NOT* to give SYNCSORT an opportunity to exploit this 
performance enhancement before they get around to doing so in DFSORT. 
So, in answer to my original question, they should have said there were 
not yet any *IBM* exploiters...



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: z14 specific instructions?

[Ed Jaffe]

On 6/5/2019 9:27 AM, John McKown wrote:


...I am now looking at the EXECUTABLE=NO
operand of the STORAGE OBTAIN. I already check the z/OS level "02.02.00" or
greater to dual path my assembly code. But I have also read that although
z/OS 2.3 will accept this operand, on anything less than a z14, it is
ignored. So I am trying to make sure that the person assembling the code is
targeting a z14 or above.


Why? Who cares what kind of machine you're running on? If it's an older 
machine, you just get the old behavior because the new behavior doesn't 
exist. On a new machine, you get the new behavior (non-executable 
storage). Either way, it's all good...



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: I Want An OPTABLE Built-In Function

[Ed Jaffe]

On 4/3/2019 12:58 AM, Jonathan Scott wrote:

Ref:  Your note of Tue, 2 Apr 2019 19:20:49 -0700

To check whether a machine operation code is supported in the
current OPTABLE, use the operation code attribute, O'opcode.



THANK YOU!


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

I Want An OPTABLE Built-In Function

[Ed Jaffe]

I realize we have _OPTABLE, but it's really hard to use because 
it doesn't return monotonically-increasing values. It gives you 
characters and 'UNI' < 'Z13' > 'ZS3'. I really want a built-in function 
I can call to tell me if a mnemonic is legit:


 LCLB  
 SETB  OPTABLE('LGFI')
 AIF   ().L1
 LLILH R1,X'7FFF'  Load bad address
 IILL  R1,X'F000'  (same)
 AGO   .L2
.L1  ANOP  ,
 LGFI  R1,X'7000'  Load bad address
.L2  ANOP  ,

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Best practice using Conditional Assembly

[Ed Jaffe]

I'd be okay with that. I'll put together an abstract...

On 3/8/2019 8:01 AM, Farley, Peter x23353 wrote:

Ed,

That sounds like a great topic for a SHARE presentation on advanced assembler 
usage, if it's not considered too proprietary to release into the wild.

Any chance of that happening?

Peter

-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Ed Jaffe
Sent: Friday, March 8, 2019 10:35 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Best practice using Conditional Assembly

On 3/7/2019 8:54 PM, Jon Perryman wrote:

Never use AREAD unless it's really needed and you are willing to code it 
correctly. Circumventing the assembler is not helpful.

AREAD/AINSERT is arguably the most powerful single mechanism in all of
HLASM. We use it *everywhere* to build tables and we've even created a
sort of "compiler" that allows us to do wondrous things. I highly
recommend its use!




This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Best practice using Conditional Assembly

[Ed Jaffe]

On 3/7/2019 8:54 PM, Jon Perryman wrote:

Never use AREAD unless it's really needed and you are willing to code it 
correctly. Circumventing the assembler is not helpful.


AREAD/AINSERT is arguably the most powerful single mechanism in all of 
HLASM. We use it *everywhere* to build tables and we've even created a 
sort of "compiler" that allows us to do wondrous things. I highly 
recommend its use!



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: IEATDUMP MF=L Can someone explain this?

[Ed Jaffe]

On 8/27/2018 4:45 AM, Charles Mills wrote:

Consider using the same list area for multiple services

Is that documented anywhere?

In other words, you are saying -- just to pick three macros that come to
mind -- I could issue an ATTACHX, an EXTRACT and a CLOSE and use the same
MF=L area for all (assuming the re-sue considerations you list)?


I've been doing that since Old Man Noah cornered the market on gopher wood!

MyDSECT  DSECT ,
MacParm DS    0D
    MACRO1 MF=L
    ORG    MacParm
    MACRO2 MF=L
    ORG    MacParm
    MACRO3 MF=L
    ORG    ,
    DS 0D
    .
    . (other stuff in MyDSECT)
    .

MyPgm   RSECT ,
    .
    MACRO1 MF=(E,MacParm)
    .
    MACRO2 MF=(E,MacParm)
    .
    MACRO3 MF=(E,MacParm)
    .
    . (etc)
    .

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: IEATDUMP MF=L Can someone explain this?

[Ed Jaffe]

On 8/25/2018 6:06 AM, Peter Relson wrote:

You mention a "DSECT".  I cannot think of any case where a list form
builds a DSECT. You might put a list form within a DSECT. But that is your
DSECT.


Indeed. Putting the list form in a DSECT is the preferred approach these 
days since (almost?) every macro written in the last 20 years has no 
requirement to copy a model parameter list from the static area before 
using the execute form.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

SHARE in St. Louis

[Ed Jaffe]

If you attended SHARE in St Louis, you were part of an 
ahhhMAZING event!


If not, here is a taste of what you missed: https://youtu.be/kL3T_6NatqI

Catch up with us in Phoenix next March...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: EX

[Ed Jaffe]

On 8/6/2018 8:23 AM, Keven wrote:

Ditto for
   EX R0,*
except that you get a 0C3 program interrupt instead, which is usually a sign of 
code scuttling itself and can be treated as such in recovery routines.


Yes, I used the 'EX R0,*' technique back in the 80s and early 90s before 
R existed. However, it requires more code to implement and does not 
work with "baseless" code. For example, let's suppose we have a "should 
never occur" condition where R1>R14.


In 2018, I will code:

CGR   R1,R14
JH    *+2

Using the old-school 'EX R0,*' technique, I would need to code:

IF CGR,R1,GT,R14
  EX    R0,*
ENDIF ,

which generates a conditional branch *around* the 'EX R0,*' instruction. 
Both are effective, but for performance reasons I prefer a branch that 
is never taken to one that is always taken. Also, these days I don't 
have a base register covering my code, so I would need to use EXRL 
instead which only works on z10 and higher machines.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Address Space TCB Structure

[Ed Jaffe]

On 6/17/2018 7:47 AM, esst...@juno.com wrote:

.
Many Years ago I attended an MVS/XA structure and logic class.
.
In that class there were diagrams of the TCB Structure for Started Task, Batch 
Jobs, and TSO logon address space.
I'm talking about the address space TCB structure (Region Control Task, Dump 
Services, STC Control, etc.).
.
Are these diagrams available with z/OS. and if so where can I Find it ?


You can use the MVS DUMP command to create an SVC dump for each of the 
three different types of address spaces. Then, in IPCS:


1. Select option '2' (Analysis)

2. Select option '6i' (Level 2 Toolkit)

3. Select 'TCBMAP'


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Count Words?

[Ed Jaffe]

On 6/16/2018 5:53 PM, Farley, Peter x23353 wrote:

The PoP says for the Vector String instructions that "For all instructions that 
optionally set the condition code, performance may be degraded if the condition code is 
set."

Have you found that performance can be significantly (or at all) improved by 
not setting the CC in the SIMD instruction and just always extracting the 
seventh byte of operand 1 to see what is the resulting index value in a regular 
GR?


GREAT QUESTION! We have not experimented with that yet.

So far, in every case where we expect the cc to be set, we are checking 
it right away for example:


DO UNTIL=M
  VLL   V1,R15,0(R1)
  VFEEB V1,V1,V0,M1
  DOEXIT 4
  AGHI R15,-16
  LA    R1,16(,R1)
ENDDO ,

Note that the DOEXIT immediately follows the VFEEB.

Despite not seeing such cases in our code, I would speculate that if we 
had a situation where we could defer checking of the cc until later (or 
not check it at all!), it would make perfect sense to do so.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Count Words?

[Ed Jaffe]

On 6/16/2018 12:15 PM, Paul Gilmartin wrote:


I stand corrected.  Thanks.

This architecture has grown beyond human ken.  Let the compiler do it, and
hope the compiler author gets it right.


It's still understandable and VERY usable in hand-written code for real 
HLASM programmers.


It just takes the kind of "mettle" we had back in the day when we read 
PoOps cover to cover over and over and over again.


Don't give up! You can do it...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Count Words?

[Ed Jaffe]

On 6/14/2018 6:18 PM, Paul Gilmartin wrote:


Oops!  From PoOps:
 Proceeding from left to right, the elements of the second operand are
 compared with the corresponding elements of the third operand and
 optionally with zero.
"Corresponding element" is the problem.
If the second operand is 
and the third operand is 
I believe I'll never get the desired match.  TRT seems to remain
the winner.


No. Remember, these are vector operations. ALL ELEMENTS of the third 
operand are compared (in parallel i.e. simultaneously!) with the 
elements of the second operand proceeding left to right.


This is not theory. We use this HEAVILY in production software that's 
been in the field since September 2016 and it *CRUSHES* TRT!


Just try it rather than thinking you understand it from a 
misinterpretation of PoOp.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Count Words?

[Ed Jaffe]

On 6/14/2018 5:44 PM, Robin Vowels wrote:
- Original Message - From: "Ed Jaffe" 


Sent: Friday, June 15, 2018 5:34 AM

BY FAR the fastest way HANDS DOWN -- if you're looking for 16 or 
fewer characters -- is with the vector instructions...


How many words can you fit into 16 characters?


Haha! I assume that's a joke, but this is no laughing matter. SIMD is a 
"game changer" for this platform.


We use it in (E)JES for general searching of any string (the FIND 
command) within (for example) spooled reports. We use VFAEB to locate 
the first character of the search string. (This use case uses requires 
only one of the 16 possible search characters.) Once it's located, we 
then CLC on the remaining characters to see if we've found a match -- 
just the same as we would if we were using TRT or SRST. This technique 
runs *CIRCLES* around SRST, TRT, and -- of course -- straight CLC. 
Nothing else we've tried even comes close...


We also use vector instructions for bit map searches, parsing of 3270 
messages (looking for up to 16 different orders), and numerous other 
primitives throughout our infrastructure.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Count Words?

[Ed Jaffe]

On 6/14/2018 3:05 PM, Ed Jaffe wrote:

LA R1,0(R15,1R1)


Of course, I intended to type LA R1,0(R15,R1)

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Count Words?

[Ed Jaffe]

On 6/14/2018 1:50 PM, Farley, Peter x23353 wrote:

Any way you could share a code example?  Or at least pseudo code for the 
technique?


Use VL to load 16 one-byte search arguments into (for example) V0
Use VLL to load 16 bytes (or how ever many remain if <16) of the string 
into (for example) V1

Use VFAEB to find the first matching byte e.g., VFAEB V1,V1,V0,1
If CC=not found, adjust string pointer up by 16 and remaining length 
down by 16 and loop back to the VLL (or exit if none left)
Otherwise, use VLGVG to get the matching ELE index from V1 into (for 
example) R15
Point to matching byte in the string by adding index value to the 
current string pointer e.g., LA R1,0(R15,1R1)


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Count Words?

[Ed Jaffe]

BY FAR the fastest way HANDS DOWN -- if you're looking for 16 or fewer 
characters -- is with the vector instructions...


On 6/14/2018 12:18 PM, Paul Gilmartin wrote:

Is there a modern, clever, efficient way to count words in a string where:
o A separator is  or  (+ others ad lib.)
o A word is a maximal non-empty sequence of consecutive non-separator 
characters.
(Whew!)

Do TRT and CLI remain the best primitives?  (TRT is reported to
perform badly, perhaps model-dependent.)

Yah, I know: "The compiler knows best!"

-- gil




This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: BAKR Instruction

[Ed Jaffe]

On 5/28/2018 2:57 PM, Peter Relson wrote:

-- You might find that use of BAKR by the caller poses an unnecessary
dependency between the caller and the callee. Consider the alternative of
calling via BASR, and the callee deciding whether to save/restore regs via
BAKR/PR or via STMG(+STAM)/LMG(+LAM).


I find that BASR imposes an unnecessary dependency between the caller 
and callee in that the callee is generally expected to be running in the 
same AMODE as the caller or at the very least callee's address must be 
reachable in the caller's current AMODE.


I realize BAKR does not set/change AMODE and therefore my suggestion may 
be slightly off topic but, in this tri-modal, 21st-Century world in 
which we find ourselves coding, might I respectfully suggest BASSM/BSM 
linkage be used instead of BASR/BR?


That's what we now do *everywhere* for cross-program linking -- we still 
use BAS/BASR/JAS/JASL for same-program linking -- and have not once 
(yet) regretted the time spent performing that mass conversion...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Dependent USING Does Not Work as Documented

[Ed Jaffe]

On 4/23/2018 12:41 AM, Jonathan Scott wrote:
[snip]

It would have been possible for HLASM to provide a simple fix for the
20-bit dependent USING case but we were holding it back because we felt
that compatibility considerations could limit our options for a more
general solution which was being designed at the time, but which never
got approved because of concerns that it would require incompatible
changes to the USING headers, the USING map and the corresponding ADATA
records.

Perhaps we should go ahead with the simple fix anyway. I'll try to
schedule another look at that item some time soon.


Thank you! Anything you can do to improve this situation will be highly 
appreciated!


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole  use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not a intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message  and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Dependent USING Does Not Work as Documented

[Ed Jaffe]

On 4/22/2018 8:20 PM, Charles Mills wrote:

or I would not have posted!

Well, I've seen dumber questions. 


Haha! So have I, but this is *ME* we're talking about! Just saying... LOL

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole  use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not a intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message  and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Re: Dependent USING Does Not Work as Documented

[Ed Jaffe]

On 4/22/2018 7:45 PM, Charles Mills wrote:

And if you make the filler X'4000' rather than X'8000', then it assembles 
without error?


Haha! Indeed ... or I would not have posted!

This post is, of course, a simplified illustration of the problem. The 
real world case that brought this to light did not use filler but rather 
actual data areas which grew steadily until finally "blowing" a 4K base 
register! Didn't expect that AT ALL...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole  use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not a intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message  and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Dependent USING Does Not Work as Documented

[Ed Jaffe]

HLASM Mavens,

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.asma400/depuse.htm 
discusses dependent USINGs. The syntax is as follows:


>>-+-+-USING-+-base-+-,address-><
   +-label---+   '-(base-+--+-)-'
   '-sequence_symbol-'   '-,end-'

where:

address
    Is a simply relocatable expression that represents an implicit
    address within the range of an active USING instruction. The
    range of an active USING is considered to be that which is valid
    for generating 12 bit or 20 bit displacements.

This statement about 20-bit displacements appears to be incorrect. Any 
attempt to specify an implicit "address" outside the range of a 12-bit 
displacement generates msgASMA307E. For example:


.  R:4 00    199  USING BigArea,R4
.00 EB80 4F40 0156 001F40    200  OIY   Byte,Bit
.    201  USING TinyArea,Byte
.** ASMA307E No active USING for operand Byte
.06    00    202  OIY TinyFlag,Bit
.** ASMA307E No active USING for operand TinyFlag
.00    00 001F48 204 BigArea  DSECT ,
.00  205  DS 8000X'00'
.001F40  206 Byte DS    XL1
.  80    207 Bit   EQU   X'80'
.001F41  208  DS    XL7
.00    00 01 210 TinyArea DSECT ,
.00  211 TinyFlag DS   XL1
.    213  END   ,

Is there any way to make this work as documented?

Thanks,

Ed Jaffe

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole  use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not a intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message  and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Terminal Talk Podcast

[Ed Jaffe]

Listen to me being interviewed on the Terminal Talk Podcast with Frank 
DeGilio and Jeff Bisti! Amazingly, I didn't say anything that needed to 
be bleeped out! LOL

http://terminaltalk.net/PodcastGenerator/?name=2018-03-25_episode_41_-_ed_jaffe_-_phoenix_software_-_3_26_2018.mp3

--
Phoenix Software International
Edward E. Jaffe
Chief Technology Officer
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Fair comparison C vs HLASM

[Ed Jaffe]

On 1/22/2018 7:44 AM, Jon Perryman wrote:

If anyone tells you C is superior to HLASM, don't believe it.


I agree with a lot of what you've written. We use SPMs for our coding 
(with FLOWASM of course) and a LOT of powerful macros for calling 
services, building tables, etc.


One thing I do like from C is that the compiler can optimize the object 
code for a particular generation of hardware -- automatically taking 
advantage of new instructions as they become available. In HLASM the 
instructions are hand-coded and therefore cannot be automatically optimized.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Dynalloc (was Macro processor)

[Ed Jaffe]

On 12/23/2017 8:18 AM, Jon Perryman wrote:

People are clever and will find ways to abuse things if they are motivated. 
Dynalloc can easily be exploited. It's not exploited because no one has been 
motivated to exploit it.


Security risks are big news in this century and there have been some 
*outstanding* mainframe security-related presentations at SHARE, GSE/UK, 
DefCon, DerbyCon, and elsewhere by "White Hats" like Phil Young 
("Soldier of Fortran"), Chad Rikansrud ("Big Endian Smalls" -- Best 
Session Award winner at SHARE), Mark Wilson of RSM Partners (also a Best 
Session Award winner), Brian Marshall from Vanguard, and others. These 
guys hack mainframes for a living! You can read their blogs and 
interviews, download their presentations, and even watch them on video 
in some cases. Just Google their names if you want to know more...


AFAICT, none of these experts caution against the use of DYNALLOC. It's 
simply not seen as a risk to the platform.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: LT Instruction After Compare And Swap

[Ed Jaffe]

On 12/19/2017 1:16 PM, Charles Mills wrote:

Isn't there some issue with using SUSPEND or RESUME if the caller of the code 
in question might hold locks and you have no control over that (such as in a 
system exit)?


Haha! Yes, and that applies to WAIT and PAUSE as well. The secret is to 
architect things such that asynchronous requests while locked are not 
necessary.


And, that's just the tip of the iceberg on the restrictions present when 
locked! You really can't do much of anything...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: LT Instruction After Compare And Swap

[Ed Jaffe]

On 12/18/2017 6:02 PM, Tony Harminc wrote:


I wouldn't want to have to argue the case for having an enabled
application program do spin loops. But we don't know the context this
code was found in; maybe it's part of an OS or a standalone program.


In my entire IT career, most of which has been spent developing system 
software, I have never once had to resort to a home-grown spin lock. 
Long, long ago I authored a FIFO "lock manager" based on the examples 
found in the Principals of Operation. It has served us well for decades. 
The same logic works whether the pool of locks is local storage or 
global storage. As long as both asynchronous units of work have some way 
of waiting and being posted (and that might be SUSPEND/RESUME for 
preemptible class SRBs), then a spin lock should *never* be required.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: LT Instruction After Compare And Swap

[Ed Jaffe]

On 12/18/2017 2:45 PM, esst...@juno.com wrote:

In the code fragment above why is the LT (Load and Test) instruction necessary ?
What was the author trying to accomplish after Compare and Swap ?


This is a spin lock, not a suspend lock.

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Posting

[Ed Jaffe]

On 12/14/2017 12:03 PM, MELVYN MALTZ wrote:

Did you receive the original post ? If not...why ?


Irrelevant. Every spam filter is unique. Your experience with your 
particular spam filter is unique to you on no one else...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Address of a Literal

[Ed Jaffe]

On 12/9/2017 3:38 PM, Phil Smith wrote:

Of course, so-called "high-level" languages like C should be so lucky as to have the 
power of assembler macros! Their idea of a "macro" is really quite primitive.


Agreed! HLASM macros might very well be the most powerful pre-processor 
language in existence...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Access registers

[Ed Jaffe]

On 12/3/2017 8:44 PM, Sudershan Ravi wrote:

Hi,
Why do we use access registers?


Because it would damn-near impossible to reference data spaces and other 
address spaces without them. LOL


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: BDAM files

[Ed Jaffe]

On 11/27/2017 11:52 AM, John McKown wrote:


​Well, I don't do much basic I/O, so maybe I'm confused. But doesn't an
AMODE(31) program require more work than AMODE(24) or maybe I'm thinking
RMODE(31)? Or is that just for QSAM program (DCBE and so forth)?​


Back in the day, you had to be in 24-bit mode to call the services, so 
everyone had to write so-called "glue" routines.


The only restriction these days I can think of is that the DCB must 
reside below 16MB (virtual). That's because the DCB pointer in the DEB 
is only three bytes long.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: BDAM files

[Ed Jaffe]

On 11/27/2017 11:22 AM, John McKown wrote:

​BDAM is a "traditional" access method, like BSAM. So it cannot be _easily_ 
used by
AMODE(31),RMODE(31) programs.


Wht?! AMODE(31) callers were supported by the very, very first 
release of DFSMS!


Gosh I can't remember how many decades ago that was, but it's been a 
long, long time...



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: BDAM files

[Ed Jaffe]

On 11/27/2017 10:48 AM, Sudershan Ravi wrote:

Why BDAM files are infrequently used? what are the complexities we face when we 
do Direct Access of a file.


Before 3390s, disk geometry used to change every few years. That caused 
a lot of folks to switch to VSAM.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: A modest proposal: LE enabled HLASM + C runtime

[Ed Jaffe]

On 11/19/2017 9:45 AM, Charles Mills wrote:

Subtract?

Sort of. My impression -- and I would be happy if someone could definitively
confirm or correct me -- is that leap seconds are of course subtracted from
the TOD value, but the value in CVTLSO is negative, so adding CVTLSO
subtracts the leap second count. On the test LPAR that I am currently
looking at CVTLSO is zero, so that's not much of a clue.
http://www.longpelaexpertise.com/toolsTOD.php supports my thinking.


We do this in (E)JES:

   * Convert Local TOD (Passed in R1) to GMT
Cnvt_LclTod_to_GmtTod DC 0H
 LLGT  R15,FLCCVT  Point to CVT
 USING CVTMAP,R15 http://www.phoenixsoftware.com/

Re: ASCII self-defining constants

[Ed Jaffe]

On 10/18/2017 1:19 AM, Jonathan Scott wrote:

... We normally use code page 1047 for product code anyway,
where square brackets are hex AD and BD as in TEXT code pages and
the C/370 compiler.  I think that the ASCII translation should
probably use 819 rather than 7-bit ASCII as the target code page,
and should be made sensitive to the existing CODEPAGE option,
which currently only affects Unicode. Also, the CODEPAGE option
should be extended to cover a wider range, including 1047.


YES! We've been using code page 1047 for about 20 years or so for all 
mainframe programming environments! (Code page 37 is a distant and 
painful memory...)


The assembler's "hard-wired" ASCII<->EBCDIC support has never been of 
any value to us. We do literally *everything* dynamically (at run time) 
based on the customer's locale and a large CSECT full of accurately 
hand-crafted translate tables.


Having said that, if we had usable ASCII translation support to/from 
code page 1047 from the assembler, we would gladly start using some 
compile-time ASCII constants.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Rehabilitated TROT Routine (Was: Detection of Compile-Time Self-Modifying Code)

[Ed Jaffe]

On 10/12/2017 7:36 AM, Steve Smith wrote:

FWIW, we use local proprietary SPM set, so the syntax and expansions
aren't likely to be exactly like IBM's or yours.


We use IBM's. I heavily modified them and distributed those 
modifications to interested parties back in the day.


Eventually, IBM accepted all of my contributions (altered as necessary) 
and so I no longer maintain them. [My name even appears in 
SASMMAC2(ASMMSP). For legal reasons, IBM differentiated between NEXTWHEN 
(a new macro) and all of my other modifications, which were updates to 
existing macros. I had to sign a document giving them free and 
unencumbered use of NEXTWHEN, which I gladly did. Saved me the trouble 
of maintaining that modification.]


For the record, John Dravnieks in Perth, Australia did a great job 
incorporating my changes as well as implementing numerous other 
improvements to IBM's macro set! It went from rather "klunky," with 
numerous silly coding restrictions, to very usable with few coding 
restrictions in a fairly short time when John was around!


We do have additional modifications to ASMMSP that we use internally 
(such as allowing EQU symbols to be used with CASE instead of just 
numbers), but we've never distributed any of those additional modifications.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Rehabilitated TROT Routine (Was: Detection of Compile-Time Self-Modifying Code)

[Ed Jaffe]

On 10/11/2017 2:18 PM, Steve Smith wrote:

The equivalent I have is DOWHILE,TROT,R14,R2,B'0001'  -- the last
operand could be O, or it could be an UNTIL loop with NO (and any
other typical condition).  But we allow bare condition-code masks,
too, especially for cases where the mnemonics aren't really mnemonic.


The SPMs we use also allow direct specification of the CC if you prefer 
numbers, etc. It will generate 15-x where 'x' is whatever you've specified.


I don't understand the use of WHILE in your example. In most languages, 
WHILE tests the condition *before* the first loop iteration and UNTIL 
tests after.


Here's what I get if I specify UNTIL=NO:

.4506 B982    36995 ¦ XGR   R0,R0    Ensure no stop char
. 36996 ¦ DO UNTIL=NO    Do for all chars
.450A B992 00E2   37014 ¦ : TROT  R14,R2   Convert to hex
.450E A714 FFFE 450A  37015 ¦ ENDDO ,    EndDo

And here's what I get if I specify WHILE=O:

.4506 B982    36995 ¦ XGR   R0,R0    Ensure no stop char
.450A A7F4 0004 4512  36996 ¦ DO WHILE=O Do for all chars
.450E B992 00E2   37015 ¦ : TROT  R14,R2   Convert to hex
.4512 A714 FFFE 450E  37016 ¦ ENDDO ,    EndDo


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Rehabilitated TROT Routine (Was: Detection of Compile-Time Self-Modifying Code)

[Ed Jaffe]

On 10/11/2017 12:05 PM, Tony Harminc wrote:


The rightmost bits of the register that are not used to form the
address, which are bits 61-63 in the doubleword case and bits 52-63 in
the 4K-byte case, are
ignored but should contain zeros; otherwise, the program may not
operate compatibly in the future."


That has to be one of the worst hardware implementation decisions of all 
time! How much silicon would it have taken to generate PIC 006 if the 
ignored address bits are not zero?


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Rehabilitated TROT Routine (Was: Detection of Compile-Time Self-Modifying Code)

[Ed Jaffe]

On 10/11/2017 12:05 PM, Tony Harminc wrote:


What do the DO and ENDDO macros do here? Do they generate a test for
CC=3 and loop? That seems like a lot of assumption to build into a DO
macro...


.4506 B982    36995 ¦ XGR   R0,R0    Ensure no stop char
. 36996 ¦ DO UNTIL=NO    Do for all chars
.450A B992 00E2   37014 ¦ : TROT  R14,R2   Convert to hex
.450E A714 FFFE 450A  37015 ¦ ENDDO ,    EndDo

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Rehabilitated TROT Routine (Was: Detection of Compile-Time Self-Modifying Code)

[Ed Jaffe]

On 10/10/2017 1:52 PM, Ed Jaffe wrote:


Actually, that clarification is worth the cost of this exercise. So in 
this particular case, so long as R0 isn't any of the obvious 
two-character values C'00' - C'FF' it should work!


Thanks to input from Tony Harminc and others, we have rehabilitated this 
routine so that it now conforms to standards:


|      XGR   R0,R0   Ensure no stop char match
|      DO UNTIL=NO   Do for all chars
|        TROT  R14,R2  Convert to hex
|      ENDDO ,   EndDo

It looks a lot better without the ORG/DC/ORG and nonsense comment about 
OPTABLE(YOP) being an issue. Best of all, it works!!!


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Detection of Compile-Time Self-Modifying Code

[Ed Jaffe]

On 10/10/2017 12:20 PM, Steve Smith wrote:

D*** it, I used to know that!  Great catch.

Rewind all that about CC=1.  In *this* case, purely from a technical POV.

On Tue, Oct 10, 2017 at 3:14 PM, Tony Harminc  wrote:

So it's the table *output* characters that are matched against the
character in R0 - not the input. For TROT that character is a 16-bit
one, and your hex table is only 512 bytes long, is sparse, and is not
going to contain  or any of the other 65279 values you could
choose arbitrarily to avoid ending prematurely with CC=1.


Actually, that clarification is worth the cost of this exercise. So in 
this particular case, so long as R0 isn't any of the obvious 
two-character values C'00' - C'FF' it should work!


I'm guessing our "rogue cowboy" ex-employee didn't realize that either 
or he wouldn't have bothered to go to so much trouble to subvert 
OPTABLE(YOP) to unnecessarily set M3=1. He could have left M3=0 and 
simply done XGR R0,R0 to avoid a stop character match.


So nothing has changed except that (by pure blind luck) this particular 
code fragment works in the field. Haha! Even a stopped clock is right 
twice a day... :-D


I like Paul Gilmartin's idea of a LOCTR with non-overlay attribute. Any 
DC at a location below the highest-known value for that LOCTR would 
trigger a diagnostic. I might be able to issue my own MNOTE in a macro I 
could OPSYN for DC if I could detect the current location and 
highest-allocated location in my current LOCTR. Unfortunately, I don't 
remember seeing  symbols containing those values. Perhaps 
requesting such symbols would be a first step RFE. Something like 
_CURLOC and _HWMLOC could come in handy for other uses as 
well...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Detection of Compile-Time Self-Modifying Code

[Ed Jaffe]

On 10/10/2017 10:47 AM, Tony Harminc wrote:


Ironically, for this example, assuming the table is the standard one
that converts each byte to its 2-byte hex character representation,
the mask bit will never make any difference to the processing at any
architectural level. You *do* have to ensure that R0 contains a value
such as zero that is not in the table, but it is, as you say, only a
possible performance advantage. But there can be no restarting or
looping because CC 1 cannot be set in this case.


The source hex bytes can contain any arbitrary values 00-FF. There is no 
value for R0 that can avoid the stoppage. He would have needed some 
exception routine to handle CC=1, manually MVC in two bytes appropriate 
to the stop character, advance the pointers, and loop back. That 
exception code didn't exist, so this routine simply fails on older 
machines. Even if that CC=1 exception code was there, I would still be 
upset about the use of ORG/DC to update the instruction!




Ed made it clear that this isn't about this particular instruction in
this particular case, but rather is a matter of programmer management
and/or technical means to catch out bad practices.


To me, as a vendor, this is actually a good idea.

Which part is a good idea? I trust you don't mean sneaking in code
from a higher architectural level than allowed by policy...


GOD I hope that's not what he means! Especially not the part where you 
ORG back over an instruction to make it behave differently than coded! 
Yikes! Did we just find another "cowboy?"


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Detection of Compile-Time Self-Modifying Code

[Ed Jaffe]

On 10/10/2017 6:54 AM, Steve Smith wrote:

IF the code to handle CC=1 is there, then you are right.


There was no such code, but that would be a case where "above board" use 
of ACONTROL OPTABLE with surrounding PUSH/POP would be condoned. As we 
raise our hardware minimums, we scan for ACONTROL OPTABLE use and remove 
them as necessary. (We do similar things as we raise our operating 
system minimums as well. We look for SYSSTATE, testing of CVTOSLVL bits, 
etc. and remove code path bifurcation where it makes sense to do so.)


To be clear, ORGing back over an instruction to change it is not (nor 
will it ever be) allowed by our policies! It's clearly subversive!


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Detection of Compile-Time Self-Modifying Code

[Ed Jaffe]

On 10/10/2017 7:45 AM, Paul Gilmartin wrote:


Slightly more feasible would be an option on LOCTR declaring that only
code or only data may oppear governed by that LOCTR, and that code LOCTRs must
not be overwritten.


I LIKE that!!!


Some non-z architectures have additional segment protection enforcing the
distinction between code segments and data segments at execution time.


And z/Architecture supports this as well. That's why we have the 
EXECUTABLE=YES|NO keyword on the STORAGE and IARV64 macros:


[EXECUTABLE={SYSTEM_RULES|YES|NO}] *
    is an optional keyword input that specifies if *
    code can be executed from the storage being    *
    obtained on a machine that has implemented *
    Instruction-Execution-Protection.  The setting of  *
    EXECUTABLE=NO will be ignored when executed on a   *
    machine that has not implemented   *
    Instruction-Execution-Protection or is not running *
    an appropriate level of z/OS.  *
    DEFAULT: SYSTEM_RULES  *
   *
    EXECUTABLE=SYSTEM_RULES    *
    Code will obey the current system defaults.    *
   *
    EXECUTABLE=YES *
    Code will be able to be executed from the  *
    obtained storage.  *
   *
    EXECUTABLE=NO  *
    Code will not be able to be executed from the  *
    obtained storage on a machine that has *
    implemented Instruction-Execution-Protection.  *

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Detection of Compile-Time Self-Modifying Code

[Ed Jaffe]

On 10/10/2017 2:49 AM, retired mainframer wrote:

Has your legal team considered the possibility of industrial sabotage?  It 
would be pretty hard to argue that this defective code was accidental.


It's funny. Someone joked about that just yesterday, wondering if this 
person was collecting two salaries! LOL


I know he felt "shackled" by OPTABLE(YOP) and was always pushing for me 
to raise our hardware support minimums. I wouldn't do so for the reasons 
I have already explained.


Honestly, I think he just really, Really, REALLY wanted to use TROT to 
generate a hex dump of bytes instead of the "tried and true" UNPK/TR we 
use everywhere else throughout our code. I suspect he rationalized his 
subversion by saying to himself, "Oh, Ed's just being silly. Nobody runs 
hardware like that anymore..." and, in doing so, once again raised his 
defiant insubordination to the level of potentially jeopardizing our 
customers' businesses (and OURS!).


[Aside: You'd be surprised how old some hardware is in DR sites, even in 
very, very large companies with massive budgets! And, nothing is worse 
than having mission critical software fail in DR!]



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: Detection of Compile-Time Self-Modifying Code

[Ed Jaffe]

On 10/9/2017 10:05 PM, Paul Gilmartin wrote:



Obviously, the right way to code this would have been to use ACONTROL OPTABLE 
with surrounding PUSH/POP to get the newer TROT function. ...
  

Why would that be right?  It's still inserting an instruction unsupported
at a hardware level you intend to support.  Or is it dual-path at execution
time?


Of course, one should ensure any execution path is traversed only by 
hardware that supports the instructions used. That's beyond the scope of 
my comment.


I was merely pointing out the proper way to code an instruction from 
another OPTABLE is to use ACONTROL OPTABLE with surrounding PUSH/POP. 
ORGing back to modify an instruction is HIDEOUS! Generating the entire 
instruction using DC would be even worse!


[snip]


Does HLASM know whether you're changing an instruction or data?  Should it 
simply
notify of all negative ORGs?


I don't want notification of all negative ORGs. Only DC's that overlay 
previously-generated instructions. Something not unlike the existing 
RENT option...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Detection of Compile-Time Self-Modifying Code

[Ed Jaffe]

Like most ISVs writing HLASM code, we use OPTABLE to ensure our 
programmers don't accidentally use instructions that aren't available on 
older machines that we must still support.


Currently, we're using OPTABLE(YOP) because our minimum supported OS is 
z/OS 1.12. (It's not until z/OS 2.1 that we can leap ahead to the z9 
machines.)


We recently terminated a reckless/destructive/rogue/cowboy programmer 
who would routinely and subversively insert "land mines" into our code 
without anyone knowing. Someone found another one this week:


|    DO UNTIL=NO   Until all chars processed
|  * Until we break free from OPTABLE(YOP), the ORG game must be used
|  TROT  R14,R2  Convert to hex
|  ORG   *-2 ORG back to set M3 field
|  DC    X'10'   M3 = 1 to suppress stopper
|  ORG   ,   ORG back
|    ENDDO ,   EndDo TROT

Obviously, the right way to code this would have been to use ACONTROL 
OPTABLE with surrounding PUSH/POP to get the newer TROT function. But, 
doing so could raise the visibility of the sabotage to the level where 
someone might notice. So, he chose to alter the instruction via ORG/DC. 
(IMHO, ORGing back to change an instruction is a form of self-modifying 
code, which we don't allow.)


It might be nice if the assembler could generate an error or warning 
message if an instruction is modified at compile time.


Thoughts?

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: interesting, to me, new z14 instruction: BIC

[Ed Jaffe]

On 9/15/2017 10:37 AM, Richard Kuebbing wrote:

Not just an adcon but a "real address"!


In real mode only. A virtual address otherwise...

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

Re: PLO

[Ed Jaffe]

On 8/12/2017 3:35 PM, Charles Mills wrote:

Or phrasing the issue differently, I now have working queue management code 
using CSG and CSST. It is hard for me to envision how TBEGIN would be so 
advantageous that I would tear into this (tricky!) working code and re-write it 
for a second logic path.


I think simple queue management can be done with constrained 
transactions. The non-constrained variety would be most useful in those 
situations where you must obtain an ENQ or LATCH, make a bunch of 
updates, and then release the ENQ or LATCH. Not definitive, just my $.02 
worth...


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

Re: PLO

[Ed Jaffe]

On 8/12/2017 2:20 PM, Charles Mills wrote:

Let me volunteer to be the dumb one here.


Note that use of transactional processing is inherently dual path.
You would still need the "other" path even if every machine in the world 
already supported TBEGIN.

Why?


A non-constrained transaction needs a fallback path to deal with 
anything other than CC=0 from TBEGIN. If you get CC=1 or CC=3 you really 
have no choice but to go to the fallback path. You could retry after 
CC=2, but you don't want to get into a loop doing so. So you really need 
to set a single-digit retry limit and go to the fallback path when it's 
reached.


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

Re: PLO

[Ed Jaffe]

On 8/11/2017 6:31 AM, Blaicher, Christopher Y. wrote:

PLO is an expensive instruction.  It can do a little or a lot.  There are about 
10 pages in the POP to describe it.
However, until transactional processing is supported in all environments, 
ISV's, who never know what environment they are running under, need to keep 
using the PLO instruction.  OK, Peter, we could dual path it, but who likes to 
maintain dual paths?


Note that use of transactional processing is inherently dual path.

You would still need the "other" path even if every machine in the world 
already supported TBEGIN.


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

Re: Question about CPUs

[Ed Jaffe]

On 7/30/2017 9:57 PM, Charles Mills wrote:

Until the z13 (?), for example, NI, OI and XI
were interruptible within a reference to a single byte. NI is actually
fetch, AND, store. It could be interrupted between the fetch and the store.
So two processors doing NI or OI on the same byte could get "logically
impossible" results.


That changed waaay back with the z196...

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

Re: Question about CPUs

[Ed Jaffe]

On 7/30/2017 6:32 PM, Phil Smith wrote:

Robert Netzloff wrote:

Not sure, but is not MVCL interruptible?

Yes, that one is. Good catch! I've seen it happen, too. Makes sense: you MVCL 
more than one page, and one of them is paged out, so it has to stop while the 
page fault happens and it comes in. CLCL too, of course. And MVCLE and CLCLE.


No, MVCLE and CLCLE are *not* interruptible. They are far more modern 
instructions that move a relatively small number of bytes, update the 
registers, and set a condition code that is tested by software for a 
loop back if needed. For example:


| DO UNTIL=NO   Do for MVCLE
|   MVCLE R14,R0,C' ' Copy with blank pad
| ENDDO ,   EndDo

Such instructions require far less silicon and/or millicode to implement 
than the interruptible, 1970s-era MVCL and CLCL instructions.


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

Re: LOC=64 executable code?

[Ed Jaffe]

On 7/28/2017 2:29 PM, Ngan, Robert wrote:

There were severe restrictions on LOC=64 code before (mainly, must be 
non-interruptible)


Those restrictions were lifted six years ago beginning with z/OS 1.13.

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

Re: LOC=64 executable code?

[Ed Jaffe]

On 7/27/2017 5:14 PM, Ngan, Robert wrote:

Just noticed that the z/OS 2.3 manuals mention EXECUTABLE=YES|NO parameter for 
IARV64 GETSTOR requests.
Anyone have a summary of what kinds of code we can move above the bar in z/OS 
2.3?


You can move code that invokes no services or invokes only services that 
support RMODE(64) execution.


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

Re: Save areas (not XPLINK).

[Ed Jaffe]

On 6/12/2017 7:14 PM, Paul Gilmartin wrote:
  
Doesn't the multiplicity of linkage conventions severely erode

the usefulness of tracebacks found in dumps?  Or is there a
one-fits-all dump formatter that can recognize the various save
area formats found in a multi-language job step and make sense
of all?  XPLINK?  Java?  Rexx?  Classic 31-bit?  64-bit?  ...?


The IPCS save area trace seems to work just fine...

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

Re: Save areas (not XPLINK).

[Ed Jaffe]

On 6/12/2017 6:40 AM, Steve Smith wrote:

Regardless of the meaning of "standard", IBM does provide the IHASAVER
macro to assist with those choices.

I routinely make save areas 18D (or update from 18F) these days.


I make mine 36D to cover whatever format might be used now or in the 
future...


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

Re: Did IBM replace all format RXE with RXY ?

[Ed Jaffe]

On 1/17/2017 7:38 AM, somitcw wrote:

Does IBM plan to back-off the change from RXE to RXY and
go in a different direction or are they just sloppy about keeping
the first part of the manual insync with the rest?


According to Dan Greiner, the Principles of Operation is accurate and 
IBM is neither being sloppy nor backing off any promised change. He writes:


"If one bothers to notice the heading under which [the cited text] appears:

 * In Chapter 7, “General Instructions”:

 –Thirty-nine instructions provided by the
 long-displacement facility are added. With  the exception of the
   new LOAD BYTE  instruction, the instructions added by the
   long-displacement facility have names and  functions that are the
   same as existing  instructions (but the mnemonics and opcodes are
   new). The new instructions are of formats RSY, RXY, and SIY and have
   a 20-bit signed displacement instead of a 12-bit unsigned displacement.

 –All previously existing format-RSE and  format-RXE
   instructions are changed to be of formats RSY and RXY, respectively,
   by  use of a previously unused byte in the  instructions. These
   changes are not  marked by a bar in the margin.

 –Five instructions provided by the  message-security
   assist are added.

Thus, this statement regarding format-RSE and -RXE instructions applies 
only to those in Chapter 7.  A similar statement follows re: format-RSE 
instructions in Chapter 10.


I wasn't involved in the initial design of long displacement, but as I 
recall, there was much discussion as to whether there was a need to 
extend the HFP and BFP instructions that access storage.  Other than 
adding long-displacement forms of LOAD (LEY, LDY) and STORE (STEY, 
STDY), they decided against it. As you will have noticed with the newer 
DFP and vector instructions, the vast majority are register-to-register 
instructions; there are precious few that have storage operands.  I 
suspect this trend may have influenced the decision to not extend the 
existing HFP and BFP operations to long-displacement forms."



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

Re: Finding Dave Bond

[Ed Jaffe]

On 12/8/2016 10:35 AM, Ed Jaffe wrote:
He lives in Switzerland and works for L^z Labs -- the latest John 
Moores kill-the-mainframe endeavor...


Haha! That superscripted 'z' didn't quite work in plain text. Anyway, 
their web site URL is https://www.lzlabs.com/


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

Re: Finding Dave Bond

[Ed Jaffe]

He lives in Switzerland and works for L^z Labs -- the latest John Moores 
kill-the-mainframe endeavor...


On 12/8/2016 1:36 AM, David Cole wrote:
I guess for most people, this is old new, but I've learned only 
recently that Dave Bond is no longer involved at TachyonSoft. Does 
anyone know how to reach him these days?


You can, of course, respond to me offline.

Thanks

Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS: dbc...@colesoft.com

Home page: www.colesoft.com
LinkedIn: www.xdc.com
Facebook: www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware

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

[Ed Jaffe]

That page has been corrected so the "Click to Register" button now goes 
to the right place...


On 11/16/2016 8:26 AM, Martin Truebner wrote:

To be percise the button for "register now" points to:

http://www.share.org/share-san-jose-2017-event-registration-start

which is wrong to some extent

Martin

z/OS Bug Busterz SHARE Academy in San Jose

[Ed Jaffe]

The z/OS Bug Busterz SHARE Academy in Atlanta was a tremendous success, 
but there was room for more attendees.


Many folks complained to me throughout the week that they didn't hear 
about this amazing, Sunday deep-dive intensive until _after_ their 
travel plans were already made and asked if it could be offered again at 
a future SHARE event.


Based on this demand, we've been given the go ahead to repeat this 
incredible offering at SHARE in San Jose!


This time it's being announced well in advance, so people have adequate 
time to register and plan their trips accordingly.


http://www.share.org/san-jose-academy-zos?utm_source=prospectiveattendee_content=academy

"Back by popular demand! The SHARE Academy z/OS Bug Busterz class is 
presented by experienced z/OS Level 2 professionals and will provide you 
with the skills to analyze and make sense of diagnostic data captured by 
z/OS. You will gain the knowledge necessary to perform preliminary 
analysis of dumps and trace data using IPCS, and learn how to capture 
information through diagnostic tools, including GTF trace, CTRACE and 
SLIP. The class is designed for z/OS Systems Programmers and Application 
Programmers that support products running on z/OS, and will include a 
pre-event webcast. No prior IPCS experience is required."


NOTE: There is great demand across the various SHARE Programs for Sunday 
SHARE Academy deep-dive showcase placement, so it's unlikely we'll be 
repeating z/OS Bug Busterz again after San Jose. If you or someone else 
at your company wants to take advantage of this training, this is your 
chance!



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

Re: SRST Performance

[Ed Jaffe]

On 10/18/2016 9:11 AM, Martin Truebner wrote:

I would expect SRST to be faster - but have no data to prove it.


SRST is much, much faster than TRT but still orders of magnitude slower 
than the vector instructions.


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

Re: Not Understanding 0C4-03B

[Ed Jaffe]

On 8/29/2016 3:54 PM, esst...@juno.com wrote:

I thought LLGTR ensured a proper 64Bit Address


LLGT and LLGTR ensure a good 64-bit representation of a 31-bit address 
by setting bits 0-33 to zeros.



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

Re: Friday puzzle: CNOP 1,2

[Ed Jaffe]

On 8/19/2016 11:47 AM, Ngan, Robert wrote:

Yes, I could use LAY instead of LARL


LAY requires base register coverage, so it's not really an acceptable 
substitute for LARL.



, or I could use an aligned halfword length (which is what I've ended up doing 
for now).


We pretty much always code DC H'0' as a CNOP 1,2 equivalent.

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

Re: IBM Diassembler

[Ed Jaffe]

On 8/16/2016 4:01 PM, Joseph Reichman wrote:

Can the IBM disassembler be invoked
By a another method then submitting a job


The disassembler I use most often these days is IPCS.

IP LIST address INSTR can disassemble any code found in a dump or active 
memory.


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

Re: better way? C language x'00' delimited string.

[Ed Jaffe]

On 6/28/2016 11:36 AM, Gord Tomlin wrote:


Another good reason to use a macro. The macro could include:
 PUSH  PRINT
 PRINT NOGEN
 bla bla bla
 POP   PRINT


Or even:
 PUSH  PRINT,NOPRINT
 PRINT NOGEN,NOPRINT
 bla bla bla
 POP   PRINT,NOPRINT

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

Re: Structured Programming Macros

[Ed Jaffe]

On 5/17/2016 11:11 AM, Bernd Oppolzer wrote:

... there is only one base register
which covers the area after ENDPROC, allowing for up to 4 k of local 
static variables


Assuming your programs use 20-bit displacements like ours do, then 
you're really talking about 4K for areas that must be accessed with MVC, 
CLC, etc. and seemingly-unlimited space for bytes, halfwords, fullwords, 
doublewords, and quadwords accessed using other instructions.


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

Re: Storage Question

[Ed Jaffe]

On 4/18/2016 7:38 AM, Peter Relson wrote:

Loop
   IEANTRT to retrieve the token
   If RC indicates "token exists" then
 Leave loop
   Else if bad-RC then
 error-exit
   Obtain and fill in storage
   Set up 16 byte token to locate that storage
   IEANTCR to create the name/token
   If RC indicates "name/token already exists" then
 Free the obtained storage
   Else if bad-RC then
 error-exit
EndLoop


This is exactly what we do.

It avoids the overhead and hassle of explicit serialization in exchange 
for a _very, very tiny chance_ of briefly acquiring 2X storage.


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

Re: Microprocessor Optimization Primer

[Ed Jaffe]

On 4/4/2016 7:24 AM, Gary Weinhold wrote:
Even if there's no actual performance difference for these 
instructions, wouldn't the "not setting the CC" possibly improve the 
pipeline, since the hardware knows the next conditional branch does 
not have to wait for this instruction to be evaluated for affecting 
the CC?


Indeed! Avoiding CC "interlock" is exactly why an entire suite of 
"compare and branch" instructions were created! :-)


However, that should not apply in this situation since SLR sets the CC 
in exactly the same way as all other logical subtract instructions. Both 
SR and SLR set the CC. Only the meaning of the bits is different.


For the record, our zHISR instruction benchmark shows SLR to be exactly 
the same speed as SR, XR, etc. on our z13s (2965).


FWIW, non-grande subtracts appear to be ~9% faster than their grande 
counterparts. Not sure why...


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

Re: Csect - Dsect Question

[Ed Jaffe]

On 3/31/2016 2:03 PM, Tom Marchant wrote:


ITYM R0.


Indeed!


And the manual doesn't specify that the address returned is a clean 64-bit
address except if it is AMODE 64. So I'd suggest replacing the NILH with

LLGTR R0,R0


Empirical testing shows R0 is returned with a clean 64-bit address, even 
for an old 24-bit program:


TCB#6 RB#1 - z/XDC TPUT 
INTERFACE 

XDC ===>
_  _0E957100 0s (A.S.EDJX2) --- EJESSUBS.EJESSUBS+2100, 
EJESSUBS+2100, XPRIVATE+1A57100

_ +2100 ***
_ +2100* Empirical Test for My ASSEMBLER-LIST 
Friends*

_ +2100 ***
_ +2100 EBEF C060 0004  LMG   R14,R15,=4FD'-1' Put garbage 
in R14-R1

_ +2106 LOAD  EPLOC==CL8'IEFBR14' Load a module
_ +2106 4100 C0C0 + LA0,=CL8'IEFBR14' LOAD 
PARAMETER INTO REG 0

_ +210A 1B11  + SR1,1 SHOW NO DCB PRESENT
_ +210C 0A08  + SVC   8
_ +210E   > DCH'0' Force an abend
_ +210E   >  +0 *..*

XDC ===> L RWREGS
_ RW0  _00EC5000 _0001  _7F363434 
_
_ RW4  _7F33A71E _0E9747CE  _0041 
_F000
_ RW8  _7F466D00 _7F33C1A4  _7F33A000 
_0E955000
_ RW12 _0E98E7B0 _7F466E00  _ 
0001_


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

Re: Csect - Dsect Question

[Ed Jaffe]

On 3/30/2016 7:05 AM, Scott Ford wrote:

I have a need to create message table, with the following attributes:

1. MSGID = 9 chars
2. Length of msg
3. Message

I would like this "tab;e" in loose terms to be external. I have never done
external dsects. Am in right i can do that , create a external message
table, bring it into
storage and index into it to find messages ?   If so where can I find a
example ..


For example:

MsgEntry DSECT ,
MsgIdDSCL9
MsgSize  DSXL1
MsgText  DSCL80
MsgLenth EQU   *-MsgEntry

Code LOCTR ,Switch to code
...
 LOAD  EPNAME==CL8'MSGTABLE'Load external message table
 NILH  R1,X'7FFF'   Turn off AMODE indicators
 NILL  R1,X'FFFE'   (same)
 STG   R1,MsgTable  Save clean table address
...
 LLGH  R4,MsgNumGet message number
 AGHI  R4,-1Make relative to zero
 MGHI  R4,MsgLenth  Compute offset into table
 AGR4,MsgTable  Point to message entry
 USING MsgEntry,R4 http://www.phoenixsoftware.com/

Re: ASSEMBLER-LIST Digest - 6 Jan 2016 to 8 Jan 2016 (#2016-7)

[Ed Jaffe]

On 1/11/2016 4:18 PM, John Walker wrote:

How does BPAM relate to BTAM?  I was looking at this and finding a great 
similarity to old-fashioned PC basic dynamic reads.  Can this be used on any 
modern mainframe?


IBM stopped shipping BTAM years ago but, if you've kept the libraries 
around, it still works! :-)


The same might be true for TCAM as well, but alas in my location its 
libraries got lost somewhere in the shuffle... :-(


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

Re: BPAM multiple members/one DCB and EODAD exit?

[Ed Jaffe]

On 1/8/2016 4:21 PM, Thomas David Rivers wrote:

  I'm quite willing to "live" with that, but the driving of the
  EOD exit is the real "big" thing at the moment...


I think that might not get reset until the next FIND DE=.

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

Re: Use of LQ results in ASMA080E?!

[Ed Jaffe]

On 1/5/2016 8:49 AM, mar...@pi-sysprog.de wrote:

one can use the HLASM on z/OS (it's there anyway) and

then use your "binder/linker" to produce stuff that can then be
processed by LNKEDT in z/VSE


We run HLASM on z/OS (it's there anyway) and send the object decks via 
NJE to a VSE system for linking, but GOFF isn't supported. (I wonder if 
there is an existing requirement for this?)


I agree it would be nice to be able to insert a job step on the z/OS 
side to transform a GOFF object into something consumable by z/VSE -- 
either object deck or phase.


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

Use of LQ results in ASMA080E?!

[Ed Jaffe]

Check this out...

Try to assemble the following test program. Attempts to use AIALENTH as 
a duplication factor fail with 'ASMA080E Statement is unresolvable' 
while BIALENTH works just fine. Why?


AIADSECT DSECT ,
AIAVRS   DS0CL512
 DS32LQ
AIALENTH EQU   *-AIADSECT

BIADSECT DSECT ,
BIAVRS   DS0CL512
 DS32XL16
BIALENTH EQU   *-BIADSECT

TEST CSECT
 DC(AIALENTH)X'00'
 DC(BIALENTH)X'00'
 DC(AIALENTH)X'00'
 DC(BIALENTH)X'00'
 END

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

Re: Assembler exercise - MAX of two or more equates

[Ed Jaffe]

On 6/17/2015 2:55 PM, David Cole wrote:
Excellent! Just stuff that into an ignorable dsect, and there you go! 
I never thought of this method. Very creative.


We use the same basic technique in a robust set of macro-based math 
functions to to ensure one EQU is greater or less than another, to 
ensure a set of EQU values are all equal, to compute the max/min of the 
set, etc. Such functions come in quite handy...


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

Option to Prevent Data Loss Due to Truncation of Nominal Value

[Ed Jaffe]

A working program had the following code:

018000  MVC   0(8,R1),=CL8'EJESPOP' Set command name
018010  MVC   8(8,R1),=CL8'PATHNAME'Set command parameter

An overzealous programmer, trying to be helpful, changed it to:

018000  MVC   0(16,R1),=CL8'EJESPOP PATHNAME' Set cmd name/parm

which introduced a problem that wasn't discovered until a very 
inopportune time.


Of course, there is no substitute for thorough testing. But, it occurs 
to me that the assembler could issue a warning when data is lost from 
truncation as the result of a nominal value requiring more bytes than 
are explicitly specified via a length modifier.


Single-byte character constants are the data type in which I'm 
interested, but an argument might exist for supporting this for other 
data types as well.


Note: according to the book, double-byte character constants can't be 
truncated, fixed-point constants can't be truncated if it will result in 
data loss, and floating-point constants are rounded.


Is there a way to achieve what I want using existing HLASM R6 options? 
If not, is a requirement already on the books?


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

Re: SHARE Video

[Ed Jaffe]

On 3/9/2015 8:29 PM, Steve Smith wrote:

Nice cameos, Ed... they wouldn't give you a vocal part? :-)


Thanks! No vocal part, but they did triple my volunteer salary. ;)

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

SHARE Video

[Ed Jaffe]

If you weren't at SHARE in Seattle, you missed an incredible event. You 
also missed this...

https://www.youtube.com/watch?v=vpNfinTuPz4

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

Re: Macro to generate DS or DC

[Ed Jaffe]

On 10/3/2014 6:22 AM, Robert A. Rosenberg wrote:
I can see how the displacement between CSECTS can be computed by the 
Assembler but this displacement can be wrong once the object deck is 
link-edited/bound since the order of the CSECTS are not fixed. Unless 
the LARL references RLDs (and thus adjusts for the location in the 
program object or load module (as occurs with ACONS) any reference in 
one CSECT to a location in another CSECT can be wrong.


Cross-CSECT relative addressing, adjusted as needed across module 
rebind, has been supported since z/OS 1.8.


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

Re: Macro to generate DS or DC

[Ed Jaffe]

On 10/3/2014 8:36 AM, Paul Gilmartin wrote:

Would the programmer be well-advised to use Binder ORDER commands lest
SMP/E service reorder CSECTs and move a target out of relative addressing
range?


Unnecessary. LARL and its ilk have an addressing range considerably 
wider than the largest supported program object.


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

Re: Macro to generate DS or DC

[Ed Jaffe]

On 10/3/2014 1:10 PM, Paul Gilmartin wrote:


Oops!  I had thought program objects could be up to 16M;
relative addressing limited to +-1M.  Which is wrong?
(Both?)


You might be thinking of 20-bit (i.e., long) displacements, which have 
a range of 1M (512K in each direction). LARL and its ilk have a range of 
8G (4G in each direction). See Principles of Operation.


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

Re: Macro to generate DS or DC

[Ed Jaffe]

On 10/3/2014 2:35 PM, Paul Gilmartin wrote:


Does RMODE(SPLIT) work between RMODE(24) and RMODE(64)?  That
could very quickly get a 4GiB reach.


No.

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

Defunct? (Was: ASSEMBLER-LIST Digest)

[Ed Jaffe]

On 10/1/2014 6:53 AM, John Walker wrote:

This is pretty much a defunct area, isn't it?


No.

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

Re: Abbreviation and truncation (was: ... macros ...)

[Ed Jaffe]

On 7/29/2014 11:09 AM, Hall, Keven wrote:

I imagine a more fanciful set of rules was responsible for the single-letter 
abbreviations of the system commands.

P is the last letter of STOP; it's where it stops and the p sound is 
distinct...


Haha. Or, simply working forward alphabetically, 'S' was already taken 
with START, 'T' was already taken with SET, 'O' was already taken with 
LOG, and 'P' was the only letter left. :D


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

Re: The rationale for using macros i

[Ed Jaffe]

On 7/25/2014 8:17 AM, Paul Gilmartin wrote:

On 2014-07-25, at 08:40, John Gilmore wrote:


We disagree, sharply.  The abbreviation of long keyword/set element
values using the notion of a case-independent disambiguating
truncation is 1) convenient and 2) easy to teach in the sense that
programmers and others come to understand it quickly.
  

And here, I take Fred's side.


I LOVE abbreviations for interactive commands and their operands ... and 
HATE them in any kind of source code.


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

Re: The rationale for using macros i

[Ed Jaffe]

On 7/28/2014 6:43 PM, Paul Gilmartin wrote:

I think we agree to a point.  What about in a pedagogic context?
If you were writing an example in a manual for a novice operator,
would you write:

 CANCEL J(1234)

or:

 C J(1234)


My preference in documentation tends toward using the shortest possible 
command and operand abbreviations in any examples, but I can see both 
sides...


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