Re: RES: Reseting RMODE

[Steve Smith]

This conversation is making less and less sense.  Since when does TPUT use
a DCB?

On the original question: RMODE sets a flag on the module that ultimately
tells program fetch to load your program above or below the line (or bar,
these days).  Once loaded, what do you expect to happen on an RMODE
change?  You want program fetch to somehow delete the above the line copy
and reload it below? Sorry, but that's ridiculous.  If you think your code
needs to be RMODE 24 for any reason, then it must be always.

sas


On Sat, Dec 2, 2023 at 5:48 AM João Reginato  wrote:

> I use TPUT sometimes as a trace tool only and it uses a DCB that must be
> below the line.
> As I just use it in debugging situations, and inside a macro, that was
> easiest to me do this way.
> But the discussion is not the TPUT but RMODE. That was just a sample.
> There are some other situations that need to change it.
> I'll read more about RMODE(SPLIT).
> thanks
>
>

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Steve Smith]

Same as above.

On Mon, Nov 13, 2023 at 1:50 PM Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On 11/13/23 08:23:44, Schmitt, Michael wrote:
> >>> As long no one ever uses DISP=MOD
> >
> > ...or checkpoints. Checkpoints can cause short blocks to be written.
> >
> > (My knowledge is with IMS/DB GSAM checkpoints.)
>
> How does checkpoint interact with RECFM=VBS?
>
> --
> gil
>

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Steve Smith]

While the original question isn't really about assembler, it is at least
about programming.  This tangent has nothing to do with either... if you
want uninformed speculation on random topics, that's what IBM-MAIN is for.

sas

On Mon, Nov 13, 2023 at 9:48 AM Seymour J Metz  wrote:

> I believe that the OP wanted a solution for BSAM. If VSAM is an option
> then it's a nobrainer.
>
> Does anybody know whether CI size = block size for PDSE and zFS (linear)
> data sets? VSAM used to use multiple blocks for a CI.
>
>

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Steve Smith]

I suspect that a dive into the Unix side is not what he wants to do.  But
it's an interesting idea.

My suggestion was primarily for BSAM with POINT.  That seems to meet the
OP's needs.  The BDAM mention was an aside, and would be overkill.

Although I might say BDAM deserves more respect than it gets from IBM.
Nevertheless, I don't think it would be smart to start developing anything
based on it.  There are easier and better modern alternatives, such as
RRDS, ESDS, LDS, Unix files... I spent a few years working with BDAM
programs & files that would have naturally fit LDS.  But, LDS hadn't been
invented yet, so we made do.

sas


On Sat, Nov 11, 2023 at 5:19 PM Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On 11/11/23 06:59:07, David S. wrote:
> > To help resolve a question posted to a LinkedIn group I manage:
> > www.linkedin.com/feed/update/urn:li:groupPost:910927-7128598004344786944
> > ... I'd like to find out if there's any way to achieve *true*
> > Skip-Sequential processing with a Fixed Block Sequential File with a
> fairly
> > short record length (i.e. DCB=(DSORG=PS,RECFM=FB,LRECL=80)?
> > For example: Begin sequential processing at record number 100, *without*
> > having to read the first 99 records.
> >
> >
> This feels like a job for DSFS.
>  >
>
> UNIX readily solves the problem with seek() and DSFS is supposed
> to mimic a UNIX file with the content of a Classic data set.
>
> Where's the User's Guide for DSFS?
>
> Is the skip count fixed, or is it dynamic, varying up or down
> with successive executions of your program?
>
> --
> gil
>

Re: Is True Skip-Sequential Processing Possible with RECFM=FB,DSORG=PS?

[Steve Smith]

Sure it's possible... BSAM POINT should work fine in general, and BDAM is
even more powerful.  However, the previous mention about short blocks is
important; that will foul up block calculations, so you'd probably want to
make it FBS, and make sure there are no short blocks.  Presuming your
application knows what record it wants to start with, you'll have to
calculate the TTR and block offset from that.  And of course, by using
BxAM, you have to do your own de-blocking, and I/O overlap.

sas

Re: Based vs. Relative (was: Internal Exit Routine Handling)

[Steve Smith]

Ah, right.  20-bit displacements don't apply to branching instructions.

I've never seen any use of short or long relative addresses that wasn't
consistent, i.e. signed offset in halfwords.

sas

On Fri, Nov 10, 2023 at 8:13 AM Seymour J Metz  wrote:

> I'm not aware of any branch instructions with a 20-bit offset. For LAY the
> offset is signed, giving +/- 512 Mi bytes.
>
> I haven't checked, but I believe that all of the relative instructions use
> signed offsets.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
>
>

Re: Based vs. Relative (was: Internal Exit Routine Handling)

[Steve Smith]

You forgot the 4th, 20-bit based signed displacement (Y & G-suffixed
instructions).  Just to have a chance at misremembering, I think that's
about +/- half a MB.

sas

On Thu, Nov 9, 2023 at 1:33 PM Seymour J Metz  wrote:

> There are  only three sizes:
>
> legacy, 12 bits, unsigned, 4 Ki byts
> relative, 16 bits, signed, +/- 32 Ki HW = +/- 64 Ki bytes
> relative long, 32 bits, signed, +/- 2 Gi HW = +/- 4 Gi bytes
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
>
>

Re: Variable-Length Parameter List Attributes

[Steve Smith]

I agree!  However, for products that are distributed and maintained with
SMP/E, keeping the object decks is generally done to facilitate building
APAR fixes and PTFs.  I haven't looked into the possibilities, but I
haven't seen automatic library call used with SMP/E, except for
IBM-provided call libs like SYS1.CSSLIB.

sas

On Thu, Oct 19, 2023 at 10:58 AM Farley, Peter <
0dc9d8785c29-dmarc-requ...@listserv.uga.edu> wrote:

> This is quite a normal practice in a large shop with many shop-wide or
> utility subroutines used by multiple applications.  When you link / bind a
> "main" program you want the link editor / binder to automatically find the
> executable code for all the subroutines you call (and all the ones that
> they in turn call) in the SYSLIB DD (which is usually a concatenation of
> many libraries).  Linking / binding the subroutines means you do NOT have
> to code a bunch of INCLUDE statements as input to the link editor / binder
> for the "main" program, it will just happen automatically.
>
> Using "NCAL" for the subroutine link / bind step is also quite normal and
> means that the lower-level subroutines that the application subroutines
> call are NOT included in the subroutine  load module / program object, so
> you keep the size of your "executable code" library to a minimum, and all
> subroutine calls are resolved at link / bind time of "main" programs.
>
> Maintaining a deck of INCLUDE statements in parallel with source code
> changes for "main" programs that can introduce or remove called subroutines
> is a maintenance headache that no one needs.
>
> Peter
>
> From: IBM Mainframe Assembler List  On
> Behalf Of Schmitt, Michael
> Sent: Thursday, October 19, 2023 9:50 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Variable-Length Parameter List Attributes
>
>
> At my company, the standard going back at least 37 years has been to
> compile or assemble, then the job immediately NCAL links the object deck
> into an "object module" (not to be confused with PDSE "program object").
> The object deck is discarded, the object module is saved.
>
>
>
> I'm not sure *why* we do this, except that it makes it easier to link the
> object into composite load modules.
>
>
>
> Is this common? Or do other groups save the object deck?
>
>
>
> -Original Message-
>
> From: IBM Mainframe Assembler List  On
> Behalf Of Jonathan Scott
>
> Sent: Thursday, October 19, 2023 7:31 AM
>
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>
> Subject: Re: Variable-Length Parameter List Attributes
>
>
>
> In the past, DC 0H'0' was preferred for defining labels because
>
> any DS, even of zero length, would cause a new TXT card to be
>
> started in the object deck, making it larger than necessary.
>
> The value is no longer needed, so DC 0H is allowed.
>
>
>
> If no alignment padding is required, DC 0H and DS 0H are
>
> equivalent, but if alignment padding is required (which would
>
> not occur within instructions) then DC 0H will pad with a zero
>
> byte and continue on the same object code TXT card, but DS 0H
>
> will simply start a new TXT card at the aligned location.
>
>
>
> Jonathan Scott, HLASM
>
> IBM Hursley, UK
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> e-mail and delete the message and any attachments from your system.
>

Re: Variable-Length Parameter List Attributes

[Steve Smith]

Thanks Jonathan for the explanation... I doubt that many people care much
about the tidiness of their object decks (but I am one :-).  That is only
part of the reason I insist on using DC over DS in text sections though.

The main reason is that any padding generated is shown in the listing,
which can be important.  Also, even in DSECTs, I often use DC for most
fields, because you get a visual layout of the fields in the listing, not
just a bare offset. Particularly in a "control block" type DSECT, it's
useful for finding places where new fields can be tucked in without making
the block larger.  No text is generated for DSECTs, so there's no cost to
using DC over DS, other than having to code a value for fields that aren't
0-length.

Long ago, DS for largeish areas was better because no text was generated in
the object deck (or load module).  But in a strictly reentrant world, DS
space in a module is usually pointless.  Also, the enhancement to DC 0* to
eliminate the need for the '0' value makes it a lot easier to use (and
neater).

sas

On Thu, Oct 19, 2023 at 8:42 AM Jonathan Scott 
wrote:

> In the past, DC 0H'0' was preferred for defining labels because
> any DS, even of zero length, would cause a new TXT card to be
> started in the object deck, making it larger than necessary.
> The value is no longer needed, so DC 0H is allowed.
>
> If no alignment padding is required, DC 0H and DS 0H are
> equivalent, but if alignment padding is required (which would
> not occur within instructions) then DC 0H will pad with a zero
> byte and continue on the same object code TXT card, but DS 0H
> will simply start a new TXT card at the aligned location.
>
> Jonathan Scott, HLASM
> IBM Hursley, UK
>

Re: Variable-Length Parameter List Attributes

[Steve Smith]

You can actually set LINKINST=DC,LINKOP=0H if you really like clever.

sas

On Wed, Oct 18, 2023 at 1:37 PM Ed Jaffe 
wrote:

> On 10/18/2023 10:14 AM, Farley, Peter wrote:
> > Build the parameter list once using this form:
> >
> >   CALL  (15),(PARM1,PARM2,PARM2,BLOCK,PARM5),VL,MF=(E,PARMB),   X
> > LINKINST=NOPR,LINKOP='0'
>
> Nice!
>
> I remember when LINKINST was added (and have used it for both BASR and
> BASSM).
>
> Never thought to set it to a NOPR...
>
>

Re: Define Flag (DF) Macro

[Steve Smith]

I think the "program type value" would be more appropriate for that
purpose.  Although I don't see much benefit as stated, maybe it could lead
to some.

sas

On Thu, Aug 17, 2023 at 12:19 PM Dave Clark 
wrote:

> Sorry, I shouldn't keep using that other thread since we are no
> longer talking about the original subject.  Anyway...
>
> Now that I'm using my own macro (DF) to generate the equated bit
> mask, how does the assembler community feel about using expression-3 in
> the EQUate instruction to define a custom data type that is not one of the
> 28 IBM-defined data types?  The manual states that this value can be 0 to
> 255.
>
> Do I want to require that the DF macro be used if you're going to
> use the SF, CF, and TF macros -- by testing for a unique data type
> assigned by the DF macro?  If so, any guidelines for selecting a unique
> data type designation?
>
> Note that the programmer would still be able to use whatever
> format (binary, hexadecimal, character, numeric, etc) for the bit mask
> operand of the DF macro, but the DF macro would assign its own (override
> the) data type for the resulting equated bit mask.
>
>
> Sincerely,
>
> Dave Clark
> --
> int.ext: 91078
> direct: (937) 531-6378
> home: (937) 751-3300
>
> Winsupply Group Services
> 3110 Kettering Boulevard
> Dayton, Ohio  45439  USA
> (937) 294-5331
>
>
>
>
> *
> This email message and any attachments is for use only by the named
> addressee(s) and may contain confidential, privileged and/or proprietary
> information. If you have received this message in error, please
> immediately notify the sender and delete and destroy the message and all
> copies. All unauthorized direct or indirect use or disclosure of this
> message is strictly prohibited. No right to confidentiality or privilege
> is waived or lost by any error in transmission.
>
> *
>

Re: Self-documenting Bit Settings

[Steve Smith]

Yeah, I was hesitant to go there on this thread, but I have a couple of
flag-intense programs that maintain them in a register (I think of it as my
"control" register).  The register immediate instructions provide all the
same operations, with the bonus they operate on 16 bits each.  Helper
macros would be more complex, but presumably save the trouble of having to
remember whether HH, HL, LH, or LL was needed for each particular flag.  As
Shmuel said,...

For the record, I coded it all without creating such macros (maybe next
time).

Note that one possible drawback of all these schemes is they don't easily
support multiple bit operations.  But that's typically not important.

sas

On Thu, Aug 17, 2023 at 7:18 AM Seymour J Metz  wrote:

> With some extra work, you could do something like this
>
> NAME FLAGS FOO+BAZ
> FOO  FLAG  X'80'
> BAR  FLAG  X'40'
> BAZ  FLAG  X'20'
>  ...
>  FON   BAR+BAZ
>  ...
>  FOFF  FOO
>  ...
>  FTM   FOO+BAR
>
> or even this
>
>
> NAME FLAGS HH,[FOO+BAZ]
> *  STORAGE - Generate DC AL1, use storage immediate
> *  HH  - Optional DC AL2, use register immediate
> *  HL  - Optional DC AL2, use register immediate
> *  LH  - Optional DC AL2, use register immediate
> *  LL  - Optional DC AL2, use register immediate
> FOO  FLAG  X'80'
> BAR  FLAG  X'40'
> BAZ  FLAG  X'20'
>  ...
> MYINIT   FDC   FOO+BAZ
>  ...
>  FON   BAR+BAZ,REG=MYREG
>  ...
>  FOFF  FOO,REG=MYREG
>  ...
>  FTM   FOO+BAR,REG=MYREG
>
> or even count bits automatically.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>

Re: Self-documenting Bit Settings

[Steve Smith]

I don't object to using the length attribute this way, but with another
macro, you can avoid that.  We have a set of macros that define, test, set,
or clear flags very easily, but use a definition macro works like so:
 @FLAG 
_A EQU *-1
_V EQU 

The other macros look like (e.g.):
  @SETFLAG FLAGX
and generate:
 OIFLAGX_A,FLAGX_V

@CLRFLAG would produce NIFLAGX_A,255-FLAG_V (of course).
You still have to code a DC B or something before the @FLAG macros,
labelled or not.  So, otherwise it works the same as using the length
attribute.

There are slight pros & cons to each, so I guess it comes down to
preference or possibly local standards.

sas



On Wed, Aug 16, 2023 at 10:08 AM Dave Clark 
wrote:

> "IBM Mainframe Assembler List"  wrote on
> 08/16/2023 10:05:25 AM:
> > I can see that point.
>
>
> So, now my three macros follow this pattern -- pending further
> recommendations.  Thanks.
>
>  MACRO
>TF,  TEST FLAG BIT(S)
>  AIF   (T' EQ 'O').GOOD
>  MNOTE 12,'TOO MANY OPERANDS SPECIFIED'
>  MEXIT
> .GOODAIF   (T' NE 'O').BEGIN
>  MNOTE 12,'AN OPERAND IS REQUIRED'
>  MEXIT
> .* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> .* This is a simple macro to make it easier to accurately manipulate *
> .* a bit flag definition just by  the equated bit mask name -- i.e., *
> .* the macro does not need to know  the name of the actual flag byte *
> .* nor the flag byte even have to have a name at all.*
> .*   *
> .* As presented by the late Dr. John Ehrman of IBM at SHARE. *
> .*   *
> .* The idea is,  you can have a  definition similar to either of the *
> .* following.  The actual flag byte does not need a name but you can *
> .* specify one if you want it  to  show up in the cross-reference or *
> .* if you want the equated  bit  masks  to follow the flag byte def- *
> .* inition.   The equated bit masks then take on the location of the *
> .* flag byte and the length of  the  equated  bit mask is set to the *
> .* bit mask, itself. *
> .*   *
> .* FLAG1EQU   *,B'0001'  *
> .* FLAG2EQU   *,B'0010'  *
> .* FLAG3EQU   *,B'0100'  *
> .* FLAG4EQU   *,B'1000'  *
> .* FLAG5EQU   *,B'0001'  *
> .* FLAG6EQU   *,B'0010'  *
> .* FLAG7EQU   *,B'0100'  *
> .* FLAG8EQU   *,B'1000'  *
> .*  DSBL1   MY FLAG BYTE *
> .*   *
> .* MYFLAG   DSBL1   MY FLAG BYTE *
> .* FLAG1EQU   MYFLAG,B'0001' *
> .* FLAG2EQU   MYFLAG,B'0010' *
> .* FLAG3EQU   MYFLAG,B'0100' *
> .* FLAG4EQU   MYFLAG,B'1000' *
> .* FLAG5EQU   MYFLAG,B'0001' *
> .* FLAG6EQU   MYFLAG,B'0010' *
> .* FLAG7EQU   MYFLAG,B'0100' *
> .* FLAG8EQU   MYFLAG,B'1000' *
> .*   *
> .* NOTE:  See also the SF macro and the CF macro.*
> .* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> .BEGIN   ANOP
>TM,L'   TEST FLAG BIT(s)
>  MEND
>
> Sincerely,
>
> Dave Clark
> --
> int.ext: 91078
> direct: (937) 531-6378
> home: (937) 751-3300
>
> Winsupply Group Services
> 3110 Kettering Boulevard
> Dayton, Ohio  45439  USA
> (937) 294-5331
>
>
>
>
>
>
> *
> This email message and any attachments is for use only by the named
> addressee(s) and may contain confidential, privileged and/or proprietary
> information. If you have received this message in error, please
> immediately notify the sender and delete and destroy the message and all
> copies. All unauthorized direct or indirect use or disclosure of this
> message is strictly prohibited. No right to confidentiality or privilege
> is waived or lost by any error in transmission.
>
> *
>

Re: Self-documenting Bit Settings

[Steve Smith]

> I am not familiar with AL0 and I am too lazy to look it up. By analogy to
> AL4 it *should* do pretty much nothing at all.
>

It does something.  But not what gil said.

>
> Charles
>
>

Re: Constants in MVI/CLI instructions

[Steve Smith]

MVHI and MVHHI operate on signed operands, and do sign extension.  The
point was that 255 (x'ff') isn't a negative number, and so won't produce
the 2 or 4 bytes of all ones that he wants.  Jonathan Scott has explained
the workings of HLASM absolute values more than once... it is what it is.
But fundamentally, you really can't use signed numbers in a logical context
and not expect there's going to be some issues.

There is some limited support for 8-bit signed numbers.  LB I know about,
and I have vague memories of vector support.  Oh yeah, there's CIB/J, which
also has a signed 1-byte operand.

As for the assembler "understanding".  It does what you want, you just
don't like the warning, which you prefer not to suppress.  Anyway, I think
HLASM does the best it can to accommodate all desires.

sas

On Fri, Aug 11, 2023 at 7:17 PM Jon Perryman  wrote:

> > Mark Hammack
> > YES EQU X'FF'
> > NO   EQU X'00'
> > TRUEEQU  -1
> > FALSE   EQU 0
>
> Using TRUE EQU YES makes your intent clear.  Coding X'FF' would be
> consistent. -1 should not be used.
>
> > I realize that bytes are unsigned whereas anything bigger is signed.
>
> Numbers in HLAsm are signed or unsigned and have a length of 2, 4 or 8
> bytes (ignoring float & packed).  1 byte is not considered a number.
>
> >  it would be nice if the assembler "understood" that x'FF' and -1 are
> "equivalent"
>
> In C, they are equivalent but HLAsm is warning us that it's making an
> assumption about our intent.
>
> > MVHI (and MVHHI for a halfword bool) doesn't sign extend
>
> I'm not familiar with these instructions but I assume they are for the C
> compiler. If there aren't signed equivalents, then I'm guessing the C
> compiler did not need them.
>

Re: Modifying the CC in the PSW

[Steve Smith]

So, your macro doesn't know the condition.  I was thinking of something
like an IF macro.

OK, some more unsolicited free advice (as usual maybe worth what you pay
for it).  I doubt that loading the operands into registers and comparing
them there is going to be any faster than a CLC.  It will definitely take
up more space, which may cause USING range problems.

I'll take it for granted you know all operands fit into 4 bytes.

sas

On Fri, Aug 11, 2023 at 9:09 AM David Eisenberg 
wrote:

> >I think it would much more straightforward to adjust the condition<
>
> Steve,
>
> I understand what you mean. My issue is that the macro is intended to
> replace pre-existing CLC instructions within legacy applications (the macro
> will examine and potentially modify the comparands prior to the compare).
> My hope is to code the macro in such a way that the original two CLC
> operands can be passed as positional parameters to the macro without
> swapping their order, and without the need for the developer to change any
> of the conditions in the subsequent jump instructions. I.e., my desire is
> to make the macro as functionally transparent as possible to the invoking
> applications.
>
> If it’s too nonsensical for me to modify the CC after a CLHHSI, then I’ll
> probably take the approach of putting the operands in the high-halves of R0
> and R1 and doing a CLHHR.
>
> Thanks,
>
> David
>

Re: Modifying the CC in the PSW

[Steve Smith]

I think it would much more straightforward to adjust the condition, i.e.
when you need to reverse the specified operand order, you change JL to JNL,
H to NH, NL to L, NH to H.  Might be messy in the macro, but the executable
part would be clean.

For the record, I wouldn't go down this road at all.  Every assembler
programmer has to deal with coding compare instructions, so let them handle
it.

sas

On Fri, Aug 11, 2023 at 8:09 AM David Eisenberg 
wrote:

> I’m trying to puzzle something out… I hope this question isn’t too goofy.
>
> I’m coding a macro to logically compare a halfword in storage to a 2-byte
> unsigned constant that is calculated by the macro assembler. I want to
> generate baseless code using as few instructions as possible, and I’d like
> to use the fewest number of registers possible (although I have no problem
> using the high-halves of any registers). My preference is to use CLHHSI to
> do the compare, because no literal is required for the constant.
>
> However: CLHHSI requires that the constant be the second (immediate)
> operand. There will be times when the macro parameters will indicate that
> that comparands must be reversed (i.e., where the immediate operand must be
> the first comparand), in which case I can’t use CLHHSI.
>
> I know that I can always code the comparands in the correct order by
> loading them into the high-halves of R0 and R1, then use CLHHR. Or, of
> course, I can generate a CLC with a literal. But I figured I’d ask: if I
> use CLHHSI, then (if the macro determines that it’s necessary) can I modify
> the resulting condition code to appear as though the original comparands
> were swapped? (I.e.: CC=00 stays the same, CC=01 becomes 10, CC=10 becomes
> 01.)
>
> So far, this is what I’ve come up with (just as an example of the macro’s
> generated code):
>
>  CLHHSI HALF,X'A24B' I like CLHHSI… no literal needed
>  JEDONE  if the comparands are equal, don’t modify
> the CC
>  IPM   R1
>  XILF  R1,X'3000'flip the bits in the CC
>  SPM   R1set the new CC, program mask remains
> unmodified
> DONE DS0H
>
> Is that the best I can do? Or might there be some clever way to modify the
> CC using fewer (or shorter) instructions? (Or is my entire concept
> ridiculous?)
>
> Thanks so much,
>
> David
>

Re: Macros: sublists question

[Steve Smith]

Just because a positional sublist parameter works for one (or two) thing
doesn't mean you're limited to using only positional sublist parameters.
Maybe add a keyword TYPE=EQ, or whatever makes sense?

Much more typically, the blinders are on the other side, and people forget
that a positional parameter would be much better than a required keyword of
FUNCTION=foo|baz

sas

On Wed, Aug 2, 2023 at 2:55 AM Rene BRANDT <
14a2846c6667-dmarc-requ...@listserv.uga.edu> wrote:

>  Hi David,
>
> I don't understand your need of the = sign, and a question comes to me :
> why not using a 3rd parameter ?
>
> René
>
>

Re: Shower thought

[Steve Smith]

CL instructions compare bit-by-bit from left to right until there's a
mismatch.

C instructions compare signed numbers.

That's it.  The rest is merely implications.

sas


On Wed, Jun 7, 2023 at 12:29 PM Dave Clark  wrote:

> "IBM Mainframe Assembler List"  wrote on
> 06/07/2023 01:22:23 PM:
> > So where does this "Logical" come from? I'm sure it's something obvious!
>
>
> Or to extend that a little further...  It is a character
> (hexadecimal/unsigned) comparison vs. a numeric
> (signed binary/packed) comparison.
>
>
> Sincerely,
>
> Dave Clark
> --
> int.ext: 91078
> direct: (937) 531-6378
> home: (937) 751-3300
>
> Winsupply Group Services
> 3110 Kettering Boulevard
> Dayton, Ohio  45439  USA
> (937) 294-5331
>
>
>
>
>
> *
> This email message and any attachments is for use only by the named
> addressee(s) and may contain confidential, privileged and/or proprietary
> information. If you have received this message in error, please
> immediately notify the sender and delete and destroy the message and all
> copies. All unauthorized direct or indirect use or disclosure of this
> message is strictly prohibited. No right to confidentiality or privilege
> is waived or lost by any error in transmission.
>
> *
>

Re: Assembler theology question

[Steve Smith]

On Thu, Jun 1, 2023 at 10:25 PM Phil Smith III  wrote:

> See, I knew this would get into theology!
>
>
>
> I guess I wasn't clear enough: I only meant this for when you're doing a
> single instruction, something that will never expand-this
> kind of "flyby" of a control block on the way to another. Clearly if
> you're doing a bunch, it makes more sense to do the USING.
>
>
>
> What I meant about "keeping out of trouble" is that if you make a change
> later and decide to use one of the registers as a base
> semi-globally, then having this single-line USING makes for a larger
> change. Of course you'll argue (and I'll agree) that this might
> be good, as it might keep you from stepping on that base, so I guess that
> doesn't really apply.
>

This shouldn't be an issue.  You should always DROP when the code that was
written for is done with it.  Leaving hanging USINGs that may or may not be
valid anymore certainly is looking for trouble.

So, now we're talking about 3 statements vs. 1, and I think that tilts the
answer towards the 1-instruction form.  But I agree with most of the
comments about how it depends on various other considerations.  imho, I
tend to use the one-line version for common things, but I like USINGs for
more exotic control blocks.

>
>
>
> Jeremy's comment about typos is certainly an interesting point, though
> it'll likely come clear pretty fast once run! I'm not sure
> that three lines of code vs. one represents a net savings in potential
> typos, either, TBH.
>

Yeah, you could typo the USING just as easily as the instruction
reference.

>
>
>
> I sure do love assembler.
>

I'm going to presume you mean that  both literally and ironically (I agree
dually).  While you can write gibberish in any language, only assembler
opens up the myriad possibilities of screwing up register usage.

sas

Re: How to properly integrate HLASM SECTALGN with ALIGNT in z/OS binder?

[Steve Smith]

When I learned about the binder's COMPAT default, I changed my process to
specify COMPAT(CURRENT).  So far, so good (it's been a year at least).

sas

On Wed, May 3, 2023 at 12:38 PM Jonathan Scott 
wrote:

> The effect of SECTALGN depends on the level of program object
> compatibility requested in the binder COMPAT option.  By
> default, alignment stronger than quadword is rounded up to 4K,
> for compatibility with the limitations of the load module
> format.  I think a COMPAT value of ZOSV2R1 or above is needed
> for the binder to fully respect SECTALGN alignments.
>
> Jonathan Scott, HLASM
> IBM Hursley, UK
>

Re: Blocking Low core access from Assembler programs

[Steve Smith]

It sounds incredible to me that this kind of mistake could be made so many
times and go undetected.  While the typo of CLC/MVC for CLI/MVI isn't
uncommon, it usually isn't propagated into a huge number of programs.  I'd
be pretty nervous about my future if I were in any way responsible for this.

I guess the easiest (not necessarily easy) thing would be to roll back to
2.4 until the fixes can be identified and made.

SLIP ZAD may be a useful tool for finding the bugs, but it is a debug tool,
not a way to circumvent the errors.  The other suggestions sound like
brainstorming, but none seem at all practical.  As two very authoritative
IBMers have just said.

My product actually had this bug (just one!) where AH Rx,2 was
inadvertently coded when AHI was meant.  It worked for years, because
whatever happened to be there was close enough, until 2.5, when it became
zero.  Zero led to a failure way, way down the line, and it took a while to
figure that out.

sas

On Tue, Mar 28, 2023 at 6:01 AM Jonathan Scott 
wrote:

> Preventing access is not practical.  The standard approach here
> would be to use the IEAVTSZR method documented on that ZAD web
> page to collect ZAD events and then to use the resulting report
> to identify which programs need to be fixed.
>
> Jonathan Scott, HLASM
> IBM Hursley, UK
>

Re: Symbol collisions in macro definitions

[Steve Smith]

Jonathan Scott's idea was what I thought of, (but I wasn't willing to work
through the details).

Shmuel (Seymour J.) Metz's reference to QUAL is interesting.  I'd modernize
the concept by using the standard '.' to delimit the qualifiers (I got
tired of the gratuitous use of "$" decades ago).  This seems to be very
similar to C++ namespaces (and structure elements), and it would be a very
useful addition to HLASM.

sas

Re: CLHHSI TYPECHECK(MAGNITUDE) Annoyance

[Steve Smith]

Ooops.  Missed that you were using the CL* version.  No such thing as
negative numbers in logical land.

sas

On Wed, Dec 7, 2022 at 12:00 PM Ed Jaffe 
wrote:

> On 12/7/2022 8:20 AM, Seymour J Metz wrote:
> > When you code an immediate operand, it has semantics beyond the
> generated code. An operand of -1 is signed and not equivalent to X'',
> even though they have the same value. The instruction is compare logical
> half half storage immediate, thus the assembler expects the immediate
> operand to be unsigned. I'd consider the message to be appropriate.
> >
> > Maybe define a symbol with an appropriate and use it in the CLHHSI, e.g.,
> >
> > HWMINUS1ASUNSIGNED EQU X''
>
>
> Yes, an EQUate should work. Perhaps something like UHNeg1 which is not
> syntactically longer than =H'-1' used to be.
>
>
> --
> 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: CLHHSI TYPECHECK(MAGNITUDE) Annoyance

[Steve Smith]

"The second operand is two bytes in length and is treated as a 16-bit
signed binary integer."

So, I think it's just a bug.  I haven't had occasion to use -1 with CHSI,
etc., but I have with MVHI, etc. and no such warning is emitted.

sas

On Wed, Dec 7, 2022 at 11:20 AM Seymour J Metz  wrote:

> When you code an immediate operand, it has semantics beyond the generated
> code. An operand of -1 is signed and not equivalent to X'', even though
> they have the same value. The instruction is compare logical half half
> storage immediate, thus the assembler expects the immediate operand to be
> unsigned. I'd consider the message to be appropriate.
>
> Maybe define a symbol with an appropriate and use it in the CLHHSI, e.g.,
>
> HWMINUS1ASUNSIGNED EQU X''
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
> behalf of Ed Jaffe [edja...@phoenixsoftware.com]
> Sent: Wednesday, December 7, 2022 10:46 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: CLHHSI TYPECHECK(MAGNITUDE) Annoyance
>
> We decided to replace many SS instructions with their SIL counterparts.
> One common case is frustrating.
>
> D501 C01E C020  CLC   HWord,=H'-1'Is it negative one?
> A784 000C   JENegOne  Branch if yes
>
> replaced with:
>
> E555 C01E   CLHHSI HWord,-1   Is it negative one?
> A784 000C   JENegOne  Branch if yes
> ** ASMA320W Immediate field operand may have incorrect sign or magnitude
> - -1
>
> I totally understand the warning in this case:
>
> E555 C01E   CLHHSI HWord,131071   Is it negative one?
> A784 000C   JENegOne  Branch if yes
> ** ASMA320W Immediate field operand may have incorrect sign or magnitude
> - 131071
>
> but I can't understand why -1 generates this warning. The provided value
> is validly within the range -32768 through 32767.
>
> We like TYPECHECK(MAGNITUDE) and quite literally assemble tens of
> millions of lines of code daily with it enabled and no such warnings are
> produced. So we're forced to use ACONTROL like this around this bizarre
> case:
>
>  PUSH  ACONTROL
>  ACONTROL TYPECHECK(NOMAGNITUDE)
> E555 C01E   CLHHSI HWord,-1   Is it negative one?
> A784 000C   JENegOne  Branch if yes
>  POP   ACONTROL
>
> It seems a ridiculous misunderstanding on the part of the assembler...
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.phoenixsoftware.com%2Fdata=05%7C01%7Csmetz3%40gmu.edu%7Cb8e9bc93878545f5d50608dad86a6896%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638060248795037186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=nSiNwQLluMEbqXVV7FtvNW%2BoB3oVZmxt%2BQcNN%2Fmlc7k%3Dreserved=0
>
>
>
> 
> 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: Off topic: mainframe group?

[Steve Smith]

IBM-MAIN has plenty of traffic, shows no sign of slowing down.

sas

On Tue, Nov 22, 2022 at 5:00 AM Ian Worthington <
0c9b78d54aea-dmarc-requ...@listserv.uga.edu> wrote:

> It seems that bit.listserv.ibm-main may have died, at at least have next
> to zero traffic, which amounts to the same thing.
> Anyone here know of a suitable replacement for z architectural questions?
>
>
> Best wishes / Mejores deseos /  Meilleurs vœux
>
> Ian ...
>

Re: ASMA080E Statement is unresolvable

[Steve Smith]

The answer to "why" is complicated.  It has to do with the differing
alignments, and the order in which HLASM does things.

Try putting a FTO DS 0F at the beginning of the area, and base your
length EQU on that.

sas

On Thu, Aug 18, 2022 at 9:28 AM João Reginato  wrote:

> Hi everybody
>
>
>
> Why does the asm below work fine?
>
> …
>
> 000AE6 D72F 401C 401C 0001C 0001C  1778+ XCFTOECLR,FTOECLR
>
> …
>
> 1C32951+FTOECLR  DS0CL(FTOECLRL)
>
> 1C32952+FTOAASCB DSF
>
> 2032953+FTOMTLN  DSH
>
> 2232954+ DSH
>
> 2432955+FTOJOBNM DSCL8
>
> 2C32956+FTOJOBID DSCL8
>
> 3432957+FTOSTPNM DSCL8
>
> 3C32958+FTOPSTNM DSCL8
>
> 4432959+FTOAPLNM DSCL8
>
>   00030   32963+FTOECLRL EQU   *-FTOAASCB
>
>
>
> …
>
> And the asm below doesn’t? (after few changes)
>
> …
>
> 000A32    0 0  1729+ XCFTOECLR,FTOECLR
>
> ** ASMA044E Undefined symbol - FTOECLR
>
> ** ASMA044E Undefined symbol - FTOECLR
>
> …
>
> 2032923+FTOECLR  DS0CL(FTOECLRL)
>
> ** ASMA080E Statement is unresolvable
>
> 2032924+FTOMTLN  DSH
>
> 2232925+ DSH
>
> 2432926+FTOAASCB DSF
>
> 2832927+FTOJOBNM DSCL8
>
> 3032928+FTOJOBID DSCL8
>
> 3832929+FTOSTPNM DSCL8
>
> 4032930+FTOPSTNM DSCL8
>
> 4832931+FTOAPLNM DSCL8
>
>   00030   32934+FTOECLRL EQU   *-FTOMTLN
>
>
>
> When I put FTOAASCB (a fullword) in the front, it works fine.
>
> When I put FTOMTLN (a halfword) in the front, is doesn’t work.
>
>
>
> Any tips?
>
> Regards
>
> João
>
>
>
>
>
>
>
> --
> O software antivírus Avast realizou uma checagem de vírus neste e-mail.
> www.avast.com
>

Re: YA MGCRE RCF?

[Steve Smith]

I created a macro to generate parmlists with optional specification for how
an operand is addressed.  Briefly,

CALLV program,(parm1,parm2,(parm3,Y),parm4)

where parm3 would be addressed with LAY instead of LA.  The macro actually
just appends the 2nd operand to LA (i.e. 'LA(,2)'), so it's
flexible and simple.  Obviously, this depends on the macro electing to
support that technique, and the hundreds of IBM service macros that require
addresses aren't likely to be so enhanced.

But in general, if something needs exotic addressing, you just have to get
the address into a register yourself, and pass that in.  All in all, it's
probably not enough of a problem to be worth a ton of effort trying to make
it easier.  I think Jonathan's post implies that it would be a big deal for
HLASM.

As for example code that IBM provides, I haven't seen any yet that would
pass our code review, and many that would fail to assemble.  Nevertheless,
they're useful for their purpose.  As far as I'm concerned, the base
register setup instructions are unnecessary clutter anyway.  If you need
help with that, you're in the wrong manual.

sas


On Wed, Jul 13, 2022 at 8:27 AM Peter Relson  wrote:

> Definitely the lack of an equate for R12 should be corrected (such as by
> adding an equate and a BASR R12,0). I'll get that taken care of.
>
> Almost all macros expect some amount of addressability to static data for
> certain invocations. That will not be stated for individual macros. That is
> why "baseless" coding is usually not a valid approach if using z/OS macros.
> You tend at least to need addressability to static data.
>
> The MGCRE example isn't even for that case; it needs addressability to get
> to the static data that is used (the text and consname). Macros, in
> general, have no way of knowing if they could use "LARL" so don't even try.
>
> An entertaining thought for an assembler enhancement would be a pseudo-op
> that generated "LA" or "LARL" depending on whether the target was in a
> CSECT or a DSECT (maybe allowing for LAY too).
>
> Peter Relson
> z/OS Core Technology Design
>

Re: YA MGCRE RCF?

[Steve Smith]

Most code examples in IBM manuals are pretty poor examples of coding, and
I'd think IBM would take more care with them, just because it would
make them look smarter.  Nevertheless, as Charles alluded, they serve their
purpose, and I've found them useful many times.

But I'd never copy them.

sas


On Tue, Jul 12, 2022 at 7:49 PM Charles Mills  wrote:

> Well, a doc writer giving examples has to balance between trivial versus
> overly complex, and has to make certain assumptions about the reader's
> knowledge and environment.
>
> This example is flawed as you indicate but I would find it useful. It at
> least shows the format of TEXT and CONSNAME.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Tuesday, July 12, 2022 3:45 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: YA MGCRE RCF?
>
> Well, that got terribly garbled.  Trying a different way.
>
> On Tue, 12 Jul 2022 10:30:13 -0600, Paul Gilmartin wrote:
> >Do I have cause for an RCF here?
> >
> >In  z/OS 2.5 MVS Programming: Authorized Assembler Services
> Reference, Volume 3 (LLA-SDU)
> >IBM SA23-1374-50
> >
> >I see: MGCRE - Execute form
> >
> DOMTST   CSECT
> R2   EQU   2
>  USING *,R12
>  LAR2,CMD   R2 POINTS TO THE COMMAND AREA
>  MGCRE MF=(E,LAREA),TEXT=(R2),CMDFLAG=(NOHCPY),CONSNAME=MYCON
> CMD  DS0CL6 THE COMMAND AREA
> CMDLEN   DCXL2'4'   LENGTH OF COMMAND
> CMDCOMM  DCCL4'D C 'THE ACTUAL COMMAND
> MYCONDCCL8'CON4'NAME OF ISSUING CONSOLE
> LAREAMGCRE MF=L LIST FORM OF MGCRE
>  END
>
>  It's inconsistent that there is an EQU for R2 but not R12.
>
> The content of R12 is nowhere defined, by e.g. LR R12,R15.
>
> Has this code been tested?
>
> Outside this example, the doc does not mention a need for
> CSECT addressability. Is this generally assumed,
> or must it be asserted for each macro? |
>
> --
> Thanks,
> gil
>

Re: When did logical instructions appear?

[Steve Smith]

The logical instructions were in there from the get-go.  I have no idea
what the implications were or are for COBOL.

Every coding standard should document exactly why the standard exists, i.e.
what benefit it provides.  That might help filter out, and allow for
updating, of some long-gone person's personal preferences (which is where
too many coding standards come from).

sas

On Thu, Jun 16, 2022 at 10:36 AM Schmitt, Michael 
wrote:

> My company's COBOL coding standards are* to define binary fields as signed
> (e.g. PIC S9(4) BINARY). I'm wondering why that's the standard.
>
> The original standards were developed at least 40-60 years ago. They were
> revised in 1994 but the signed binary guidance remained.
>
> One explanation could be if 50 years ago there were only signed binary
> instructions such as ADD, but not logical instructions such as ADD LOGICAL.
> Or maybe there were some logical instructions but not the full complement
> we have today.
>
> Or it could be that whatever version of COBOL was used then (OS/VS COBOL
> or earlier) was more efficient with signed binary, such as due to the
> choices it made in instruction selection.
>
> So my question is, roughly when did the machines get unsigned binary
> instructions for halfwords and fullwords?
>
>
> * "are" isn't the right word here, since the COBOL coding conventions are
> no longer published anywhere. I only know what they are because I was on
> the team that reviewed the 1994 revision, and have a copy saved.
>

Re: MVCRL

[Steve Smith]

A Relative Long field is four bytes; obviously two would not fit into an
eight-byte instruction (there's no such thing), much less six..  A Relative
Short (to coin a term) is only two bytes, so that seems feasible, as long
as a suitable one-byte opcode is available.  But then, others would want
relative to based, vice versa, and more opcodes are needed.  Or, maybe
those could be defined to use a register for the length, which would allow
12-bit opcodes, which are more plentiful.  The drawback is using a
register; but having variable-length MVCs would be a pretty good
compensation.

sas


On Wed, Jun 8, 2022 at 10:16 AM Schmitt, Michael 
wrote:

> I was imagining something just like MVC except relative.
>
>

Re: Generating a TR field

[Steve Smith]

Well, it's a moot point whether it was a good idea for HLASM to treat a
null operand and a non-existent one differently.  They can't change it now,
without yet another silly option to allow them to act the same way.

Regardless, it is a mistake for a macro to bleat out an error because an
optional parameter is null.  It's trivial to allow null to be equivalent to
non-specified.  In fact, AIF ('' EQ '') covers both.

It is certainly possible for a macro to be designed to treat non-specified
and null both as valid, but with different semantics.  Although I doubt
that's a good idea.

sas

>
>

Re: Generating a TR field

[Steve Smith]

Ed might have prioritized brevity because he's not paid to do your coding
for you.  His example is idiomatic for an experienced developer, and if
you're not experienced, then you have a learning opportunity.

I have no patience with the fear that a "maintenance newbie" can't be
expected to learn anything.  If they can't, I suggest you'd be better off
with not doing maintenance until you find someone who can.

sas

On Fri, May 27, 2022 at 11:32 AM Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On May 26, 2022, at 16:26:38, Charles Mills wrote:
> >
> > And what is that? Some comments?
> >
> My thought, but what?:
> A paraphrase of the OP's requirement?
> And/or explanation of the unintuitive semantics of:
> o "*" within a repetitive  constant definition?
> o A character self-defining term used as a numeric value?
> o "ORG" with *two* empty arguments?
>
> But no fault to Ed.  His target was a level above your
> putative "maintenance newbie" and valued brevity.
>
>

Re: Quadword constant

[Steve Smith]

If you have more than an academic interest, there's always RFE, also not
new.  In my limited world, the need for writing constants > 2G has not
really come up much.

The famous =FDS12E6'1' is about it, and already works (one second in TOD
format; multiples, up to a few hours at least, also work).

sas

On Thu, May 19, 2022 at 4:56 PM Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> > On May 19, 2022, at 14:39:49, Steve Smith wrote:
> >
> > AD
> >
> > This isn't new.
> >
>  DCAD(100*100)
> ???
>
>

Re: Quadword constant

[Steve Smith]

AD

This isn't new.

sas


On Thu, May 19, 2022 at 3:49 PM Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On May 19, 2022, at 12:16:45, Ngan, Robert (DXC Luxoft) wrote:
> >
> > FD is a fixed point doubleword.
> >
> Alas, there's no way to define a doubleword constant containing the
> value of an arithmetic expression AL8(2+2)?
>
> Having only a 32-bit assembler for a 64-bit architecture is
> increasingly becoming anachronistic.
>
>

Re: Unsigned 64-bit numbers

[Steve Smith]

Your mind is in the right place, but your text is not.  You can LGF or LLGF
a fullword into a full register.  LG loads a doubleword, whether you point
it at one or not.  i.e. an LG Rx,=X'87654321' results in x'87654321garbage'.

There now exist LGH, LH, LLGH, LLH, LGB, LB, LLGC, and LLC for all
varieties and sizes you need, not to mention the corresponding immediate
versions.

sas

On Thu, Apr 28, 2022 at 6:25 PM Charles Mills  wrote:

> 64 bits is 64 bits whether the high bit is a sign or part of the number.
> Loading 64 bits into a register loads 64 bits unaltered. The high bit
> becomes the high bit, 0 or 1.
>
> As @Gary says, it only matters when the sending field is smaller than the
> receiving register. (And then only when the sign bit is 1; a negative
> number IOW.)
>
> An LG of X'87654321' into a register gives you 87654321. An LLG
> gives you 87654321. If the source is X'01234567' then either
> instruction gives you the same result.
>
> LH and LB also do sign extension. ICM and IC do not.
>
> Charles
>
>

Re: Quadword constant

[Steve Smith]

Sheesh.  Sorry, I meant ORG *,16.

On Wed, Apr 20, 2022 at 12:30 PM Steve Smith  wrote:

> That's the old-fashioned way.  This is the new way:
>
> USING *,16
>
> There are some caveats.  For CSECTs, HLASM will complain if SECALGN is
> insufficient.  For DSECTs, it's your responsibility to ensure the alignment
> matches (if it's real important).  Fortunately, STORAGE has a corresponding
> alignment specification.
>
> sas
>
> On Wed, Apr 20, 2022 at 10:50 AM Bob Raicer  wrote:
>
>> Ed;
>>
>> Of course, what you said about the LQ type of DC is true, and I too
>> have used LQ data types in some of my code too.  However, the
>> SECTALGN requirement is a bit of an issue when assembling code with
>> 2**3 (double word) section alignment and which also contains DSECTs
>> which map quad word aligned storage areas.  I've had to resort to
>> schemes like what is shown below (I hope the list server doesn't
>> mangle the sample listing too badly).
>>
>> The reason(s) for still having double word aligned sections is (are)
>> a bit lost in antiquity -- inertia is a powerful thing :)
>>
>> : D-Loc   Object Code Stmt   Source Statement
>> :1 SAMPLE   DSECT ,
>> :2  PRINT ON,DATA
>> : 0010   3 REF  DCA(QUADITEM)
>> :0004 00 4 BYTE DCAL1(0)
>> :5 *
>> -
>> :0005    6  DC
>> (*-SAMPLE)+15)/16)*16)-(*-SAMPLE))AL1(0)
>> :000D 00
>> :7 * Round up to a Quad Word
>> :8 * boundary.
>> :9 *
>> :0010   10 QUADITEM DCXL16'00'
>> :0018 
>> :   11  END   ,
>>
>

Re: Quadword constant

[Steve Smith]

That's the old-fashioned way.  This is the new way:

USING *,16

There are some caveats.  For CSECTs, HLASM will complain if SECALGN is
insufficient.  For DSECTs, it's your responsibility to ensure the alignment
matches (if it's real important).  Fortunately, STORAGE has a corresponding
alignment specification.

sas

On Wed, Apr 20, 2022 at 10:50 AM Bob Raicer  wrote:

> Ed;
>
> Of course, what you said about the LQ type of DC is true, and I too
> have used LQ data types in some of my code too.  However, the
> SECTALGN requirement is a bit of an issue when assembling code with
> 2**3 (double word) section alignment and which also contains DSECTs
> which map quad word aligned storage areas.  I've had to resort to
> schemes like what is shown below (I hope the list server doesn't
> mangle the sample listing too badly).
>
> The reason(s) for still having double word aligned sections is (are)
> a bit lost in antiquity -- inertia is a powerful thing :)
>
> : D-Loc   Object Code Stmt   Source Statement
> :1 SAMPLE   DSECT ,
> :2  PRINT ON,DATA
> : 0010   3 REF  DCA(QUADITEM)
> :0004 00 4 BYTE DCAL1(0)
> :5 *
> -
> :0005    6  DC
> (*-SAMPLE)+15)/16)*16)-(*-SAMPLE))AL1(0)
> :000D 00
> :7 * Round up to a Quad Word
> :8 * boundary.
> :9 *
> :0010   10 QUADITEM DCXL16'00'
> :0018 
> :   11  END   ,
>

Re: Quadword constant

[Steve Smith]

HLASM has fixed BINARY constant type specifiers for H, F, FD.  The
architecture has no support that I know of for 16-byte fixed binary, so why
should the assembler?

sas

On Mon, Apr 18, 2022 at 11:06 AM Schmitt, Michael 
wrote:

> HLASM has fixed decimal constants for Halfwords, Fullwords, Doublewords,
> with appropriate alignment. Why is there none for Quadwords?
>
> The closest I see is LQ, but that appears to be intended for floating
> point.
>

Re: New z16 Instructions

[Steve Smith]

--->

On Sat, Apr 16, 2022 at 8:33 PM Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On Apr 16, 2022, at 17:32:03, Steve Smith wrote:
> ...
> Do any mnemonics use numeric digits?  Is it IBM's intention never
> to use digits in mnemonics?  (But at one time IBM seemed committed
> never to use mnemonics longer than four letters.)
>

SAM31 & its friends are all that come to mind.

>
> > Anyway, nothing here looks nearly as bad as the infamous introduction of
> > the MSG operation.
> >
> I don't know that one.  Did IBM step on its own toes?
>

I'd say it stepped on a lot of toes with that one, but not necessarily its
own.  It's one of 11 varieties of MULTIPLY SINGLE (13 inc. immediate forms).

>
> --
> gil
>

sas

Re: New z16 Instructions

[Steve Smith]

Another alternative is to OPSYN delete the new instructions that conflict.
I think that will work: I rtfm, but not tested.

Personally, I think adding :MAC would just be more work.  You might as well
rename the macro.

While I really find gratuitous usage of national character prefixes to be
ugly, it does tend to future-proof macros named with such, as I think we
can assume IBM won't ever invent an instruction mnemonic that starts with
one.

Anyway, nothing here looks nearly as bad as the infamous introduction of
the MSG operation.

sas

On Sat, Apr 16, 2022 at 5:35 PM Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On Apr 16, 2022, at 14:22:59, Ed Jaffe 
> wrote:
> >
> > We just applied this APAR to our systems:
> >
> > https://www.ibm.com/support/pages/apar/PH39324
> >
> ... which links to a "Fix Readme" with recommendations
> for dealing with possible clashes between 30 new
> instruction mnemonics and customer-defined macro names.
>
> One suggested remedy is:
> If the macro names cannot be easily changed, then
> the programs can use the ":MAC" suffix to ensure that
> the macro is used rather than the instruction.
>
> Would defensive programming recommend that all macro
> invocations use the ":MAC" suffix lest a name become
> an instruction mnemonic in the z17?
>
> An alternative not mentioned might be if references
> are numerous to COPY the affected macro definitions
> into source programs.
>
> --
> gil
>

Re: Next instruction needed

[Steve Smith]

Tom Harper made a perfectly clear proposal, that evidently only you cannot
comprehend.

I have my own opinion on its value, but I for one, don't think the world
needs to know every opinion I happen to have.

sas

>
>

Re: Edit Masks

[Steve Smith]

There's really nothing that can beat trying it out.

Moving the Sig Start earlier is usually all you need; except it has what I
consider to be the perverse effect of starting significance with the
following digit.  Which makes it impossible to include the first leading
zero naturally (because SoS picks up a digit, and suppresses it if 0).
Sometimes using C'0' as the pad works out; sometimes, you have to coerce
the input field to be longer than (1 more digits) than you want to display.

sas


On Thu, Mar 10, 2022 at 12:23 PM Charles Mills  wrote:

> Dave, you raise a good point. ED is powerful but tricky. You would have to
> read the PoOp very carefully. Sorry to wimp out here, but it has been a
> long
> time for me. I fear you are correct: that ED will happily use the
> significance starter as a fill byte, with unhappy results. For the "no
> blank
> fill" case you may have to ZAP the data to a larger field, or use UNPK and
> OI.
>
> Charles
>
>

Re: Rules for Zoned Overpunch

[Steve Smith]

You could use TRT to test the last byte, after some tedious coding of the
table.  N.B. I mean using the table codes to identify +/0/-/invalid; not
just the 0/non-0 typical use.

You could PACK the field, or just the last byte (which is just a
nibble-swap), and CP to =P'0'.  The cond. code tells you what you want to
know.  You could also use AP =P'0', which returns the same cond. code, but
also normalizes the sign... but only in your test field, of course.

Or, you could use
IF TM,lastByte,B'',O
 It's +  F (or not signed, if you like that interpretation)
ELSEIF TM,lastByte,B'0001',O
 It's -  B or D
ELSE
 It's +  A, C, or E
ENDIF
Note that this is a pure sign check, i.e. 0 is not special.

The last is more instructions, but I'd guess that it would perform the best
if that matters.

sas


On Fri, Feb 11, 2022 at 1:01 PM Dave Clark  wrote:

> I know that x'F1' and x'C1' are positive and that x'D1' is
> negative.  But what if I find x'A1', x'B1', or x'E1' for overpunch values?
>  What is the shortest way (in terms of assembler instructions) to validate
> these into just two classes -- positive and negative?
>
>

Re: Hexadecimal display using vector instructions

[Steve Smith]

I finally got a chance to walk thru these with XDC.  Brilliant work!

I guess I'm going to have to find some time to learn how to do some
vectoring myself.  These routines are a big help.

Thank-you!
sas

On Tue, Feb 1, 2022 at 6:10 PM Ngan, Robert (DXC Luxoft) <
robert.n...@dxc.com> wrote:

> I originally just coded the obvious VUPKZ/MVI/TR like a UNPK/MVI/TR or
> UNPKA/MVI/TR instruction sequence, but found the performance was within 10%
> for all three variations.  It looks like most of the time is spent in the
> TR instruction. So, we need to eliminate the TR, and I came up with two
> ways to do hexadecimal display conversion using the vector facility without
> TR:
>
>  VECTOR UNPACK LOGICAL
>  VLVR03,WorkXL16Load quadword source
>  VLVR06,=C'0123456789ABCDEF' "Translate" table
>  VREPIB VR05,X'000F'Initialize AND mask
> *- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
>  VUPLLB VR07,VR03   Pad each byte in LOW doublewordX
> ... with a null byte on the left
>  VSLD  VR02,VR07,VR07,4 Shift out high order nybble
>  VNVR04,VR02,VR05   Mask out L.O. source nybbles inX
> ... H.O. vector register nybbles
>  VOVR08,VR04,VR07   Merge high/low nybble bytes
>  VPERM VR01,VR06,VR06,VR08  Translate to hexadecimal digits
> *- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
>  VUPLHB VR07,VR03   Pad each byte in HIGH doubleword   X
> ... with a null byte on the left
>  VSLD  VR02,VR07,VR07,4 Shift out high order nybble
>  VNVR04,VR02,VR05   Mask out L.O. source nybbles inX
> ... H.O. vector register nybbles
>  VOVR08,VR04,VR07   Merge high/low nybble bytes
>  VPERM VR00,VR06,VR06,VR08  Translate to hexadecimal digits
> *- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
>  VSTM  VR00,VR01,WorkCL32   Store 32 hex digits
>  VECTOR MERGE
>  VLVR12,WorkXL16   Load quadword source
>  VLVR15,=C'0123456789ABCDEF'  "Translate" table
>  VERLLB VR14,VR12,4  Swap high/low nybbles within bytes
>  VPERM VR13,VR15,VR15,VR12  Translate LOW nybbles to hex digits
>  VPERM VR11,VR15,VR15,VR14 Translate HIGH nybbles to hex digits
>  VMRHB VR09,VR11,VR13  Merge H.O. 16 hexadecimal digits
>  VMRLB VR10,VR11,VR13  Merge L.O. 16 hexadecimal digits
>  VSTEG VR09,WorkCL8a,0   Spread out hex digits, 8 per per store
>  VSTEG VR09,WorkCL8b,1   ...
>  VSTEG VR10,WorkCL8c,0   ...
>  VSTEG VR10,WorkCL8d,1   ...
>
> Both versions of the vector code run 5-20 time faster than your classical
> UNPK/MVI/TR (5-20 nSec vs. 90-100 nSec on a z15 T02).
> The UNPACK LOGICAL does 8 bytes at a time, so you can shorten the code if
> you're converting no more than 8 bytes.
> The MERGE code always does all 16 bytes, but second (low) MERGE is not
> required if not converting more than 8 bytes.
>
> In MERGE example, I'm using multiple VSTEG's instead of a VSTM to spread
> the output across 4 separate fields for legibility.
> This code will convert 16 bytes at a time, unlike UNPKA and VUPKZ which
> are restricted to a maximum of 15 bytes. And there's no "extra" byte to
> clean up on the target side, or to worry about accessibility to on the
> source side.
>
> A big thanks to Dan Greiner for his extremely helpful PowerPoints
> explaining how the vector instructions work.  But I still have no idea how
> we'd use half of those instructions in general coding. The VPERM
> instruction seems to be a (all register) TRANSLATE against a 32-byte table
> (in two vector registers), looking at only the L.O. 5 bits of each byte. I
> only needed to look at the bottom 4-bits, and achieved that by using the
> same register for both halves of the translate table.
> It's probably too complicate to hand-code, but useful if you have
> hexadecimal display macro you can generate it from.
>
> Robert Ngan
> DXC Luxoft
>

Re: Branch-and-Link nomenclature question

[Steve Smith]

FWIW, I think both the Principles of Operation and the HLASM Reference are
the epitome of manuals.

sas

Re: Branch-and-Link nomenclature question

[Steve Smith]

Not true.  If you want to quibble about semantics, it's a good idea to
learn what the semantics are.  "Branch" essentially means "update the PSW
address with something else".

CICS (for whatever reason) used to (and still does for all I know) use BALR
14,14 to invoke subroutines.  That would obviously be a NOOP if it was a
"save & branch".

sas

On Thu, Feb 10, 2022 at 1:22 PM Schmitt, Michael 
wrote:

> Then there's the point that they really are Save and (then) Branch, not
> Branch and (then) Save...
>
>

Re: Saving Caller's 64-bit Registers

[Steve Smith]

I don't know what you found, but that's incorrect.  A standard Format-4
save area is 144 bytes, and there are additional formats (5-8) that can
hold combinations of ARs and high-halves.

As previously mentioned, the Assembler Services Guide defines all this.

sas


On Thu, Jan 20, 2022 at 10:30 AM Dave Clark 
wrote:

> "IBM Mainframe Assembler List"  wrote on
> 01/20/2022 09:36:03 AM:
> > "IBM Mainframe Assembler List"  wrote
> on
> > 01/19/2022 06:05:12 PM:
> > > At program entry:
> > >
> > > STMH 2,14,your-high-halves-save-area   13 fullwords for 2-14 high
> halves
> > >
> > > At program exit:
> > >
> > > LMH 2,14, your-high-halves-save-area
> >
> > Thanks.  I take it that I shouldn't presume the caller has
> > provided an extended save area for accommodating the high halves of the
> > registers.  Thus, on entry, I save the low halves in the caller's save
> > area but save the high halves in my own extended save area?  Or is there
>
> > some other means of knowing whether or not to save the high halves in
> the
> > caller's save area?
>
>
> I found that a "standard register save area" is now defined by IBM
> as 128 bytes long.  That would be the original 72 bytes (18 full words)
> plus 56 bytes (an additional 14 full words).  But the links aren't working
> so I can't drill into any further details than that.  Does this mean it is
> only intended that 14 high halves should be saved/restored?  Would that
> omit registers 0 and 15, or what?
>
>
> Sincerely,
>
> Dave Clark
> --
> int.ext: 91078
> direct: (937) 531-6378
> home: (937) 751-3300
>
> Winsupply Group Services
> 3110 Kettering Boulevard
> Dayton, Ohio  45439  USA
> (937) 294-5331
>
>
>
> >
> >
> > Sincerely,
> >
> > Dave Clark
> > --
> > int.ext: 91078
> > direct: (937) 531-6378
> > home: (937) 751-3300
> >
> > Winsupply Group Services
> > 3110 Kettering Boulevard
> > Dayton, Ohio  45439  USA
> > (937) 294-5331
> >
> >
> >
> >
> >
>
> *
> > This email message and any attachments is for use only by the named
> > addressee(s) and may contain confidential, privileged and/or proprietary
>
> > information. If you have received this message in error, please
> > immediately notify the sender and delete and destroy the message and all
>
> > copies. All unauthorized direct or indirect use or disclosure of this
> > message is strictly prohibited. No right to confidentiality or privilege
>
> > is waived or lost by any error in transmission.
> >
>
> *
>
>
>
> *
> This email message and any attachments is for use only by the named
> addressee(s) and may contain confidential, privileged and/or proprietary
> information. If you have received this message in error, please
> immediately notify the sender and delete and destroy the message and all
> copies. All unauthorized direct or indirect use or disclosure of this
> message is strictly prohibited. No right to confidentiality or privilege
> is waived or lost by any error in transmission.
>
> *
>

Re: Unsigned Binary Formats

[Steve Smith]

Regardless of the instruction used to load the source register, CVD treats
it as a signed F-word.  So any value with bit 32 (high-order bit of lower
half) on will be converted to a negative PD number.  So,

CVD R1,DWORD
IF LTR,R1,R1,M
  AP DWORD,=P' 4294967296'
ENDIF

The modern ways are much better, but the above is what worked pre-21st
Century.

sas


On Thu, Jan 20, 2022 at 3:17 AM Abe Kornelis  wrote:

> Dave,
>
> your initial request was for conversion of an unsigned 32-bit binary value.
>
> The LGF you are using does sign extension...  I'd suggest you use LLGF
> to avoid just that ;-)
>
> Additionally, if speed is a concern, you might want to save only the
> high halves of registers
> when they may be changed during execution. In your code sample this
> would be just R2.
>
> Kind regards & success!
> Abe
> ===
>
>

Re: 64-bit registers (was: Unsigned Binary Formats)

[Steve Smith]

Um yeah... for approximately 21 years.

sas

On Wed, Jan 19, 2022 at 1:45 PM Dave Clark  wrote:

> "IBM Mainframe Assembler List"  wrote on
> 01/19/2022 01:00:07 PM:
> > I'd suggest you clear the high-order word of R2 then use CVDG.
> >
> > Would that work for you?
>
> OK, that brings up a question that I have not had to address
> before this.  Up till now I've used odd-even register pairs for 64-bit
> operations.  But I'm given to understand that all general registers are
> actually 64-bit now instead of the traditional 32-bit.  Is that correct?
> So, 32-bit instructions just use the low order 32 bits of the general
> purpose register and 64-bit instructions automatically use the full
> register -- with no register "pairs" involved.  Is that correct?
>
> Sincerely,
>
> Dave Clark
>
>

Re: Convert Zoned to Packed

[Steve Smith]

Well, I'm not familiar with the VPKZ, and if not available, or
traditionally, you must code two PACKs for pieces of zoned fields longer
than 16 bytes.  Same applies conversely for UNPK, although ED can do it
(and much more) in one pass.

The maximum lengths for SS instructions with two lengths is 16.  So, ITHM
16 zoned digits.

sas


On Fri, Jan 7, 2022 at 3:21 PM Seymour J Metz  wrote:

> ITYM more than 15 digits. The easiest way is with Vector Pack Zoned (VPKZ).
>
>

Re: Determining a group item

[Steve Smith]

When I've done similar things, I just wrote a macro to replace DS, and it
punched out the appropriate line in whatever language I needed.  Seemed to
be far easier than reprocessing source/listings/adata.

sas

Re: ADATA dump utility [was: RE: Determining a group item]

[Steve Smith]

I can't really see what you want.  ADATA is fairly dense, but it's much
easier to process than SMF data.  All the record layouts have good DSECTs
available.

Just do it.

sas

On Sun, Jan 2, 2022 at 3:31 PM Farley, Peter x23353 <
0dc9d8785c29-dmarc-requ...@listserv.uga.edu> wrote:

> Charles,
>
> Would it be possible for you to contribute only the "intelligent ADATA
> dump" code to CBT, without any of your firm's IP included?  That seems to
> be a notably generic utility that would be a wonderful contribution to the
> IBM programming community.
>
> Converting such code to other languages (MetalC, HLASM, python, etc.)
> would then be an exercise for the rest of the community to take up.
>
> Peter
>
>

Re: Hints for coding JES2 exit routines (z/OS JES2 Documentation)

[Steve Smith]

That's nonsense, so I doubt many would agree.

sas

On Mon, Dec 13, 2021 at 1:24 PM Janko Kalinic 
wrote:

>  Assembler instructions
>
>- All TM (test-under-mask) instructions should use
>BO/BOR/BNO/BNOR/BM/BMR branch instructions rather than BZ/BZR/BNZ/BNZR
>branch instructions. If this technique is used, the logic of the branch
>instruction does not have to be modified when adding or deleting flags
> in
>the instruction mask.
>
>
> Is everyone in agreement on the above branch instruction recommendation?
>
> Regards,
> John K
>

Re: Base-less macros

[Steve Smith]

Well, I messed up CLRL... it is not an SS-like instruction.

If you really can't afford to trash half of any general register, AR0 is a
convenient hidey-hole.  It's the appendix of z/Arch, as it appears to have
no functional purpose.  If AR0 can't be trashed, then surely you can borrow
a FPR.  If not, then may God have mercy on your soul.

sas

On Mon, Nov 29, 2021 at 6:43 PM Steve Smith  wrote:

> CLRL 04(r13),=C'F4SA'  ...you have USING issues, but as long as LTORG is
> within +/- 2G, no problem.
>
> I'd go with
> LLIHF 0,C'F4SA'
> CLHF 0,4(R13)
> or
> LFH  0,4(R13)
> CLIH 0,C'F4SA'
>
> So many ways to skin the cat.
>
> As usual, not tested, subject to typos, memory checks, etc.
>
> sas
>
> On Mon, Nov 29, 2021 at 6:27 PM Charles Mills  wrote:
>
>> LLILF and C?
>>
>> Charles
>>
>>

Re: Base-less macros

[Steve Smith]

CLRL 04(r13),=C'F4SA'  ...you have USING issues, but as long as LTORG is
within +/- 2G, no problem.

I'd go with
LLIHF 0,C'F4SA'
CLHF 0,4(R13)
or
LFH  0,4(R13)
CLIH 0,C'F4SA'

So many ways to skin the cat.

As usual, not tested, subject to typos, memory checks, etc.

sas

On Mon, Nov 29, 2021 at 6:27 PM Charles Mills  wrote:

> LLILF and C?
>
> Charles
>
>

Re: Base-less macros

[Steve Smith]

Using R14 as a temporary code base after a call isn't going to work in
those cases.  I'd never heard about using BIC to return (nor can I see much
reason for it).  And there are other bizarre ways to return without
restoring R14, which is not actually required by documented conventions.
For BASSM, I suppose you could just change it to USING *+1,R14, depending
on how that suits your sensibilities.  Anyway, thanks both for pointing
those out.

Nevertheless, there's hardly any reason to ban it entirely.  Everything has
caveats.  Any suggested code is provided without any warranty, and it's up
to a competent programmer to decide if & how it may or may not fit into his
or her program.  And you might want to test it once or twice.

sas

On Mon, Nov 29, 2021 at 3:58 PM Ngan, Robert (DXC Luxoft) <
robert.n...@dxc.com> wrote:

> The assembler services guide doesn't specify what is in (bottom half of)
> R14 upon return.
> Also, on return to an AMODE(64) routine via BASSM/BSM, R14 would have the
> low-order bit set.
>
> Robert
>
>

Re: Base-less macros

[Steve Smith]

My suggestion of using R14 for the base was because it's already set by the
call to the subroutine.

sas


On Thu, Nov 25, 2021 at 2:32 PM Gary Weinhold  wrote:

> The performance consideration I think would be the loading of R14
> immediately before its use in the branch instruction.  Moving it up a
> couple instructions may help.
>
>

Re: Base-less macros

[Steve Smith]

...some BASR R14, or JAS R14, etc.
USING *,R14
B *+4(R15)
DROP R14
JRC0ROUTINE
JRC4ROUTINE
JRC8ROUTINE

sas

Re: Long displacement dependent USINGs now supported

[Steve Smith]

That's great!  Explaining things like "ST   USING
STATUS_TABLE+4000,STATUS_DESC+4000  " makes people suspect me of witchcraft.

sas

Re: Base-less macros

[Steve Smith]

It is not unreasonable to require your clients to provide a literal pool.
It is not your problem, it's the user's.  Even IBM accepted this, about 30
years ago, when relative-addressing was invented.  Their macros require
SYSSTATE ARCHLVL=2 or higher to generate with literals instead of inline
data, but that's pretty archaic now.

sas

Re: PRINT OPSYN ANOP

[Steve Smith]

>From reading the APAR, it seems HLASM thought it better to produce ASMA001E
rather than (potentially) ASMA951U.  I can't see it was worth breaking Dave
Cole's scheme.  It seems that ANOP is on the "restricted" list, and you'll
have to OPSYN to something that isn't.  And hopefully that doesn't mess the
scheme up too much.  Or maybe IBM can be persuaded to allow ANOP as a
special case.

PCONTROL is great for overriding PRINT, when you really want to see what
macro authors are hiding, but it doesn't do anything for TITLE & EJECT
abuse.

https://xkcd.com/1172/

sas

Re: A problem with OPEN and CLOSE macros

[Steve Smith]

No.

On Fri, Jun 11, 2021 at 4:36 PM MELVYN MALTZ <
072265160664-dmarc-requ...@listserv.uga.edu> wrote:

> 1) An OPEN/CLOSE with MF=L,MODE=24 can be overlayed with an
> MF=E,MODE=31 (and vice-versa). This results in destruction of the
> list,
> abends would occur
>
> 2) An OPEN/CLOSE with MF=L with (say) 2 entries can be overlayed with an
> MF=E with 3 entries. The end-of-list bit isn't touched, but a storage
> violation
> occurs
>
> It is true that the "DFSMS Macro Instructions for Data Sets" does warn
> against mixed mode and MF=L/E length differences with the usual
> 'unpredictable results may occur'
>
> The first problem doesn't worry me, but the second one does, look at this
> cut-down code...no apologies for it being contrived...if I wanted to hide
> it, I could do...
>  LA  2,8-1
>  EX R2,EXMVC
>  LR5,EXMVC
>  OILF  R5,X'00FF'
>  OPEN  (DCB2,OUTPUT,(R5)),MF=(E,HERE24O),MODE=24
>  EX R2,EXMVC
>  ...
> HEREDC8C'A'
> THERE  DC8C'B'
> *
> DCB1 DCB   ...
> DCB2 DCB   ...
> *
> HERE24O  OPEN  (DCB1,INPUT),MF=L
> EXMVC  MVC   THERE(0),HERE
>
> Using OPEN/CLOSE to subvert code sends this into another dimension
>
> I've been exchanging Emails with Mark Nelson (RACF Development) about this
> and have offered a solution, I can quite understand why IBM aren't keen on
> it
>
> 1) The OPEN/CLOSE list structure must change
> The 'new' structure needs an 8-byte header
> eg.
> DC C'OPCL'  eyecatcher
> DC X'mode bit'
> DC XL3'no. of entries'
>
> 2) The OPEN/CLOSE SVC processors must be able to detect the 'old' and
>'new' formats in order not to disturb existing code
>
> 3) OPEN/CLOSE MF=E will have extra coding for the 'new' format only, to
> detect both mode and storage violation errors...setting an error code
>
> Whether this is worth doing is largely up to the user community, I would
> be worried if an innocent looking macro could subvert program code
>
> Your thoughts ?
>
> Melvyn Maltz.
>

Re: [PossibleSpam] Re: AREAD question

[Steve Smith]

Right... but for the CL, you want F-word alignment anyway, although it
would only cause a trivial warning if it wasn't.

As for the "oh-so-clever" remark, it only meant reusing an adcon as the
branch target... it's a very minor point; I'd just prefer something like B
*+1 or EX Rx,* that more clearly doesn't look like an accident.  OTOH, it's
not as easy if you have no code-base.

It is very true that anything is better than a wild branch.

sas

On Mon, May 3, 2021 at 8:00 PM Tony Thigpen  wrote:

> Thanks for the alignment issue. I went back and found that a DS 0H was
> in the code in some historical copies of the macro, but not in all the
> copies. I must have fat-fingered a line delete at some point.
>
> Also, the SOC1 is only if I did not tell the macro how to handle a bad
> value. With some of my code, I am just too deep in the levels and past
> all other edits. So, as such, there should "never" be a bad value. So,
> instead of having to set up a new message or returning up the code
> levels, I want an abend so I can actually review the dump and see what
> happened.
>
> I know too many programmers that say "it will never happen" and so don't
> put some sort of trap in "just in case". Eventually, they will get burnt.
>
> Many years ago, there was a piece of software that put out a message:
> "Call Joe at x and tell him he owes Bob $10". Bob had bet Joe that
> some condition could never occur, but it did. Bob got his $10. :-)
>
> Tony Thigpen
>
>

Re: [PossibleSpam] Re: AREAD question

[Steve Smith]

Ah, OK.  If I re-coded this, there would be separate macros for each
entry.  A final end-of-table macro would set an EQU to the length needed to
generate the code.  The macros could easily be the same macro source, with
a type operand.  But overall, I think it's simpler and clearer than to pile
multiple entries into an operand list.  Much easier to add/delete entries,
too (which the AREAD version also has).

sas

On Tue, May 4, 2021 at 5:33 AM Seymour J Metz  wrote:

> The added parameter is in place of the AREAD.
>
>

Re: [PossibleSpam] Re: AREAD question

[Steve Smith]

There's no need for more parameters... just maybe a GBLA.

Frankly, I think branch tables are simple enough to code, including
automatic range checking, as to not be worth macros at all.

Whatever.

btw, HLASM is pretty smart, but it doesn't read your commentary:
A DCX''FORCE ABEND  | MUST BE TOGETHER FOR THE
C DCY(*-B)   | CL TEST TO WORK  TT 050610

You have an unaligned constant in front of an aligned one, and they have to
be together.  Lucky for you they are until someone tweaks your macro.
A DCA(*-B)

..is what you want.  That oh-so-clever S0C1 for an out-of-range value will
work just as well.

sas


On Mon, May 3, 2021 at 5:36 PM Seymour J Metz  wrote:

> The same would be true if you used macro parameters.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
> behalf of Tony Thigpen [t...@vse2pdf.com]
> Sent: Monday, May 3, 2021 5:24 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: [PossibleSpam] Re: AREAD question
>
> Because the AREAD enables building the built-in error trapping logic. If
> the reg is too large or negative, it's trapped automatically. And, I
> don't have to remember to change the limit edits every time I add
> something to the branch table.
>
> Tony Thigpen
>
>

Re: [PossibleSpam] Re: AREAD question

[Steve Smith]

Why not just have a macro to generate each entry, and not mess with AREAD
at all?

Like:
INITAPI PERF_ENT 00
ACCEPT PERF_ENT 01
...

Seems like you'd save a bunch of code, besides avoiding AREAD complications.

sas


On Mon, May 3, 2021 at 5:03 PM Tony Thigpen  wrote:

> I use LOCTR heavily in my programs. Separate areas for base code,
> basr'ed to code, lits, acons, just to name a few. It will not help me
> with this issue.
>
> The following is the code that uses the AREAD macro that I am working
> with. The macro is attached. (I have trimmed down the source call a bit
> as the real one has a lot more entries in the table.
>
>PERFORM_ON (R3),BAD_VALUE=ERRNO_2
>  INITAPI 00
>  ACCEPT  01
>  BIND02
>  CLOSE   03
>  CONNECT 04
>  FCNTL   05
>  -
>
> In reality, I think this is a very appropriate use of AREAD and I am
> just stuck with only using the macro in real program code and not in
> another macro.
>
> Tony Thigpen
>
>

Re: Ensuring LRL 2nd operand alignment

[Steve Smith]

Re LRL: The architecture doesn't enforce non-modifiabilty of your code, and
not all instructions have to be equally useful.  HLASM dies allow more
flexiblity in defining a storage constant than it does for an immediate
operand, but that's no excuse.  Sorry, that's all I've got; generally I
agree with you.

Re LGFI: The LFI instruction is named IILF.  Maybe HLASM should add an
extended mnemonic for it.

sas


On Mon, May 3, 2021 at 1:17 PM Tony Harminc  wrote:

> On a more general topic, why does LRL exist in the first place? Why
> would any programmer (or compiler) use LRL in preference to IILF or
> one of the other immediate instructions? (And why is there LGFI but no
> LFI?)
>
> Surely immediate instructions are generally faster than relative ones.
> Some of them are longer, but not in this case. Yes, of course the
> storage operand of LRL can change in a way that the immediate operand
> of IILF is unlikely to. But still, without extreme Binder tricks, I
> can't think that an operand that's at a fixed relative distance from
> the instruction is likely to be able to be placed in dynamic storage
> while the instruction isn't.
>
> Does someone have a use case for LRL?
>
> Tony H.
>

Re: Ensuring LRL 2nd operand alignment

[Steve Smith]

Your guess is incorrect. The notes you were reading explain what causes an
operation exception and what causes a specification exception.  As shown,
your instruction would not get a specification exception, as the relative
address is full-word aligned.

Regardless, instructions only require half-word alignment.  And you know
how to get full-word alignment; just apply it to your operand.

However, I have no idea where that message came from, or how accurate it is.

sas


On Fri, Apr 30, 2021 at 3:35 PM Stanislawski, Shawn (National VM
Capability)  wrote:

> Trying to use the LRL(32) instruction ('C4D' / 'C4xD' opcode).
> But running into: DMSABE141T Operation exception
>
>  -> 00DF5124  LRL C45D6832
>
> *** 00DF5124  PROG0001 -> 0139B660OPERATION
>
> Reading in the "zArchitecture Principles of Operation" (SA22-7832-12) =
> "For LOAD RELATIVE LONG (LRL, LGFRL), the second operand must be aligned on
> a word boundary,..."
> Guessing alignment is the problem.
> I know I can use a DS 0F to start the LRL instruction itself on a word
> boundary,
> but any ideas how to ensure that specifically the second operand of the
> LRL instruction will always be aligned on a word boundary?
>
>
> --Shawn S.
>

Re: Add 1, Subtract 1

[Steve Smith]

If you have to ask, it doesn't matter.

sas


On Wed, Mar 10, 2021 at 6:27 PM Schmitt, Michael 
wrote:

> I was taught long ago to add 1 to a register using LA r#,1(,r#) and to
> subtract 1 using BCTR r#,0.
>
> Is the fastest way now to use AHI r#,1 and AHI r#,-1?
>

Re: Determining AR or Primary Mode

[Steve Smith]

The instruction is IAC, in PoOp Chapter 10.

sas

On Thu, Feb 4, 2021 at 5:51 PM esst...@juno.com  wrote:

> Hello
> .
> Im looking for an assembler instruction that informs me if I'm in AR or
> primary mode.
> .
> Im on a z/OS 2,1 system-
> I thought there was an instruction that would test for AR Mode or Primary
> Mode.
> .
> I read the TAR (test Access) instruction and I don't see how that
> instruction would
> determine if a program or a routine was entered in Primary or Access
> Register (AR) mode.
> Is there an instruction to inform me of the mode ?
> Is there  different way to test ?
> .
> Paul D'Angelo
> .
> .
>

Re: A faster replacement for L R15,=A(EXTRN)

[Steve Smith]

I forgot about ASMA215W because I suppress it.  I don't think that message
is valid on z/OS; but I don't know what other considerations there are,
esp. for VSE & VM.

One of the nice things about EXTRN LARL is that there's no relocation to be
done by Program Fetch.  One of the less nice things is that every reference
makes the Binder do a bit of fix-up.  A common V-con would possibly make
more sense if there are a lot of references (by lot, probably 100s at
least).  OTOH, LLILF/IILF of a V-con would have the disadvantages of both.

sas


On Fri, Jan 15, 2021 at 1:20 PM Gord Tomlin 
wrote:

> On 2021-01-15 11:55 AM, Gord Tomlin wrote:
> > It's been possible to achieve the same result with LARL for many years
> > (requires the use of the GOFF option in the HLASM parameters).
>
> Since I got called out on the above, I ran some tests to refresh my memory.
>
> The following code:
>
>   EXTRN FOO
>   LARL  R15,FOO
>
> assembles cleanly with the GOFF option specified, but without GOFF the
> following warning message is issued:
>
> ** ASMA215W Relative Immediate external relocation in NOGOFF object text
> - FOO
>
> Regardless of whether GOFF is specified on the assembly, the output
> object module can be used to create a load module in a PDS.
>
> Revised: "It's been possible to achieve the same result with LARL for
> many years (a warning message will be issued if GOFF is not specified in
> the HLASM parameters)."
>
> --
>
> Regards, Gord Tomlin
> Action Software International
> (a division of Mazda Computer Corporation)
> Tel: (905) 470-7113, Fax: (905) 470-6507
> Support: https://actionsoftware.com/support/
>

Re: A faster replacement for L R15,=A(EXTRN)

[Steve Smith]

LARL for EXTRN does not require GOFF.  It requires the binder, the old
linkage editor can't handle it.

sas

On Fri, Jan 15, 2021 at 11:55 AM Gord Tomlin <
gt.ibm.li...@actionsoftware.com> wrote:

> On 2021-01-15 11:27 AM, Don Higgins wrote:
> ...
> It's been possible to achieve the same result with LARL for many years
> (requires the use of the GOFF option in the HLASM parameters).
>
>

Re: security with storage allocation under z.OS

[Steve Smith]

 There is a new operand on STORAGE, EXECUTABLE=YES|NO.  The default is YES,
and for earlier releases there was no execute-prevention capability afaik.

I don't know what to tell you about the "security model".  It's a big
subject.

sas

On Mon, Nov 16, 2020 at 12:24 PM Ze'ev Atlas <
01774d97d104-dmarc-requ...@listserv.uga.edu> wrote:

> Hi allIn the 1970's I probably could have done some getmain, write some
> code into that obtained memory and jump to that code.  I assume that
> nowadays, this would be impossible and there is some security model to
> prevent such a security breach.Do you know where can I find information on
> the mainframe security model under z/OS.
> Ze'ev Atlas
>

Re: Reversed string macro

[Steve Smith]

The purpose, as most know, is to generate the source for an MVCIN
instruction, which was recently discussed (maybe on IBM-MAIN?).

Turns out, I found a bug in it.  It drops characters when && or '' are in
the string.  So replace "SETA  " with "   SETA  K' ".

>From the corrected version:
1954 TAMU #REVSTR 'Texas
A& University'
12A7 A8A389A29985A589   1955+ DC
 C'ytisrevinU M& saxeT'
12AF 95E440D450C140A2

12B7 81A785E3

12BA 0014   1956+TAMU EQU   *-1,20

DCLEN is correct for the EQU length.  N.B. In case it's not clear, the EQU
defines the address of the end of the string, with a length attribute.  It
might be handy for say,

 MVCIN  @PRTHDR,TAMU
...
@PRTHDR   DSCL(L'TAMU)

sas


On Fri, Oct 23, 2020 at 8:06 AM Seymour J Metz  wrote:

> MVCIN is not a BIF in HLASM. Don't confuse what is available at run time
> with what is available at assembly time.
>
> Is there an RFE for a REVERSE BIF in HLASM? Is there a PL/I compile time
> REVERSE function?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on
> behalf of robi...@dodo.com.au [robi...@dodo.com.au]
> Sent: Friday, October 23, 2020 12:57 AM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Reversed string macro
>
> Have you tried MVCIN ?
>
> > Em qui, 22 de out de 2020 18:08, Steve Smith 
> > escreveu:
> >
> >> Submitted for your consideration...
> >>
> >>  MACRO
> >>#REVSTR 
> >> SETC  DEQUOTE('')
> >>SETA  DCLEN('')
> >> .*
> >>SETA  
> >> .LOOPAIF   ( LT 1).DONE
> >> SETC  ''.''(,1)
> >>SETA  
> >>  AGO   .LOOP
> >> .*
> >> .DONEANOP
> >>  DCC''
> >>EQU   *-1,
> >>  MEND
> >>
> >> E.G.:
> >>
> >> 3161 *
> >> 3162 #TAG #REVSTR 'IKJTCB'
> >> 3163+ DCC'BCTJKI'
> >> 3164+#TAG EQU   *-1,6
> >> 3165 #DOG #REVSTR 'The quick brown fox jumped over the lazy dog.'
> >> 3166+ DCC'.god yzal eht revo depmuj xof nworb kciuq ehT'
> >> 3167+#DOG EQU   *-1,45
>

Reversed string macro

[Steve Smith]

Submitted for your consideration...

 MACRO
   #REVSTR 
SETC  DEQUOTE('')
   SETA  DCLEN('')
.*
   SETA  
.LOOPAIF   ( LT 1).DONE
SETC  ''.''(,1)
   SETA  
 AGO   .LOOP
.*
.DONEANOP
 DCC''
   EQU   *-1,
 MEND

E.G.:

3161 *
3162 #TAG #REVSTR 'IKJTCB'
3163+ DCC'BCTJKI'
3164+#TAG EQU   *-1,6
3165 #DOG #REVSTR 'The quick brown fox jumped over the lazy dog.'
3166+ DCC'.god yzal eht revo depmuj xof nworb kciuq ehT'
3167+#DOG EQU   *-1,45

-- 
sas

Re: Conditional MVCL macro?

[Steve Smith]

So it was written, and it is so done.
sas

On Tue, Oct 20, 2020 at 6:35 PM Charles Mills  wrote:

> Unless I am thinking fuzzily, an interrupted MVCL leaves the PSW pointing
> to
> the MVCL (not past it) and the relevant registers incremented and
> decremented appropriately, so the supervisor may dispatch other tasks on
> the
> affected CPU, let them run as they will, and then resume the interrupted
> task when appropriate. The task will take off with the MVCL continuing from
> where it left off.
>
>

Re: Conditional MVCL macro?

[Steve Smith]

Interrupts can only be handled between instructions (don't ask me how
pipelining figures)  except, MVCL has the potential to delay that too
long, so it (and a handful of others) were made to be interruptible.
Probably, that just means the micro/milli-code program gets interrupted
between micro/milli-code instructions.  Possibly, that affects its
performance negatively.  Anyway, for MVCLE, the 4K limit means it can't run
very long anyway, so yeah, it does help keep interrupts flowing.

sas


On Tue, Oct 20, 2020 at 6:16 PM Keven  wrote:

>
>
>
>
> I’d say you were both correct.
> Keven
>
>
>
>
>
>
>
>
>
>
> On Tue, Oct 20, 2020 at 5:01 PM -0500, "Paul Gilmartin" <
> 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
>
>
>
>
>
>
>
>
>
>
> On 2020-10-20, at 14:58:52, Steve Smith wrote:
> >
> > There's actually a big difference between MVCL being interruptible, and
> > MVCLE stopping periodically before it's finished.  The latter is not
> > interruptible, it just stops before completion periodically for the
> program
> > to do something else if it wants to.  ...
> >
> I thought it was so that supervisor could dispatch another task.
>
> -- gil
>

Re: Another Macro question

[Steve Smith]

It's not complicated if you know how to manipulate strings in Conditional
Assembly. There's no much way around the fact it's vanity programming
though.

Besides, the technique is defeated by palindromes :-).

sas


On Tue, Oct 20, 2020 at 4:16 PM Tom Harper 
wrote:

> I already have such a macro. I’ll post it later.
>
>

Re: Conditional MVCL macro?

[Steve Smith]

There's actually a big difference between MVCL being interruptible, and
MVCLE stopping periodically before it's finished.  The latter is not
interruptible, it just stops before completion periodically for the program
to do something else if it wants to.  Checking a flag is a possibility, but
to what end I cannot figure.  Anyway, that is not possible with MVCL
(without OS assistance that does not exist).

I've heard contrary information on the relative performance of MVCL &
MVCLE.  I had no idea that MVCLE generally only moved a maximum of 4K per
iteration, which on the face of it would seem to imply it could be very
slow for large moves (particularly if your program fools around much before
re-driving it).

As for MVCL, I've heard consistently that it is considerably slower than
MVCs galore, which still puzzles me.  The explanations I've heard sound to
me like they could possibly amount to a trivial extra cost, i.e. much less
than what is commonly observed.

And for something completely different... sometimes I use MVCK for a
variable-length move instead of EX/MVC or MVCL.  I haven't done any
performance tests, because I haven't used it in performance-critical code
(and it does have a warning that it is slow).  But for programming
convenience, getting & setting the key is (at least slightly) less of an
annoyance than setting up EX.  I vaguely recall a rumor that there is an
MVCX milli-code instruction that works the same without the key
specification.  Sure would be nice if that appeared in PoOp.

sas


On Tue, Oct 20, 2020 at 3:09 PM Christopher Y. Blaicher <
cblaic...@precisely.com> wrote:

> There may be a hint to the reason for the jump in the explanation of
> MVCLE, programming note 3.
>
> "The   function of not  processing more than approximately 4K bytes of
> either operand is intended to permit software polling of a flag that may be
> set by a program on another CPU during long operations."
>
> If a similar process happens with MVCL at the 2K boundary, that could be
> the explanation.  I'm not a hardware guy, so just guessing.
>
> Chris Blaicher
> Technical Architect
> Precisely.com
>
>
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Christopher Y. Blaicher
> Sent: Tuesday, October 20, 2020 2:47 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Conditional MVCL macro?
>
> This message originated Externally. Use proper judgement and caution with
> attachments, links, or responses.
>
>
> I just re-ran a test on our z15 machine and got interesting numbers.  The
> $MVC was reasonably linear from start to finish.  The MVCL has a big jump
> from 2K to 4K, but was also reasonably linear outside of that jump.  It
> never caught up to the $MVC implementation.
>
> TEST TYPE =  BASE CODE
> CPU TIME USED=  0.003873
> TEST TYPE =  1K 4 MVC
> CPU TIME USED=  0.171274
> TEST TYPE =  1K $MVC
> CPU TIME USED=  0.183642
> TEST TYPE =  1K MVCL
> CPU TIME USED=  0.345227
> TEST TYPE =  2K $MVC
> CPU TIME USED=  0.357314
> TEST TYPE =  2K MVCL
> CPU TIME USED=  0.509385
> TEST TYPE =  4K $MVC
> CPU TIME USED=  0.704173
> TEST TYPE =  4K MVCL
> CPU TIME USED=  2.790247
> TEST TYPE =  8K $MVC
> CPU TIME USED=  1.426892
> TEST TYPE =  8K MVCL
> CPU TIME USED=  5.480536
> TEST TYPE =  32K $MVC
> CPU TIME USED=  5.835773
> TEST TYPE =  32K MVCL
> CPU TIME USED= 21.734112
> TEST TYPE =  64K $MVC
> CPU TIME USED= 12.278130
> TEST TYPE =  64K MVCL
> CPU TIME USED= 43.380435
> TEST TYPE =  128K $MVC
> CPU TIME USED= 54.570900
> TEST TYPE =  128K MVCL
> CPU TIME USED= 86.739562
>
> All the iterations used this basic set of instructions.
> *
> *TEST 1K $MVC
> *
>  SPACE ,
>  L R9,REPEATCOUNT DO IT 100,000 TIMES
>  TIMEUSED STORADR=STARTIME,CPU=TOD,LINKAGE=SYSTEM
> LOOP1A   DS0H
>  L R3,POOLADDRGET FROM ADDRESS
>  L R4,TOADDR  GET TO ADDR
>  L R5,=A(1024)MOVE 1K  BYTES
>  $MVC  (R4),(R3),(R5) MOVE IT
>  AHI   R3,1024
>  AHI   R4,1024
>  BCT   R9,LOOP1A  LOOP THE NEEDED NUMBER OF TIMES
>  TIMEUSED STORADR=ENDTIME,CPU=TOD,LINKAGE=SYSTEM
>  SPACE 3
>  LAR1,=CL12'1K $MVC'
>  BAL   R14,TIMEOUT
> *
> *TEST 1K MVCL
> *
>  SPACE ,
>  L R9,REPEATCOUNT DO IT 100,000 TIMES
>  TIMEUSED STORADR=STARTIME,CPU=TOD,LINKAGE=SYSTEM
> LOOP2DS0H
>  L R2,POOLADDRGET FROM ADDRESS
>  L R3,=F'1024'
>  L R4,TOADDR  GET TO ADDR
>  L R5,=F'1024'
>  MVCL  R4,R2  MOVE IT
>  BCT   R9,LOOP2   LOOP THE NEEDED NUMBER OF TIMES
>  TIMEUSED STORADR=ENDTIME,CPU=TOD,LINKAGE=SYSTEM
>  SPACE 3
>  LAR1,=CL12'1K MVCL'
>  BAL   R14,TIMEOUT
> The REPEATCOUNT value is 

Re: Register saving formats

[Steve Smith]

I use the IBM guidelines and haven't had a problem.  A called program that
assumes it received a 72-byte save area does not corrupt the large save
area, it just isn't "correct".  But it causes no problem.

I don't see your distinction between the save areas that provide space for
the caller's high-halves and you picking somewhere else to put them.

As far as I know, no diagnostic tool keeps up with the various z/OS linkage
conventions.  Certainly not SYSUDUMP.  It might require AI to track back
through various savearea formats, linkage stack, and LINKs, not to mention
all the things that don't follow convention.

It is messy, and the documentation is long (and boring) but IBM covered all
the bases pretty well.

sas

Re: vcon in a dsect

[Steve Smith]

The best way to put a v-con in a DSECT is to just put the v-con in the
DSECT.  Since it matters not at all, you could also just use DS A.

And do not override the length unnecessarily.  If your DSECT requires
unalignment, then it's already screwed up.  Just make every field CLn.

sas

On Thu, Sep 10, 2020 at 6:27 PM Kerry Liles  wrote:

> In a dsect I would just define it as Acon with comment that it is really a
> Vcon
>
>

Re: how to return? Let's see how good you are.

[Steve Smith]

Yes.  BAL from 24-bit is a special case.  In amode 31, it's fine.

sas

On Sat, Aug 15, 2020 at 1:30 PM Martin Trübner  wrote:

>
> >> The "special" cases, especially when R14 is loaded up separatelyWould
> you being reached by a BAL consider a special case?  L
>  15,whereverI.e. BAL 14,12(,15) go to write handlerMartinVon einem
> Smartphone gedendet.

Re: how to return? Let's see how good you are.

[Steve Smith]

Given those requirements, the only thing your subroutine needs to do is
return with BSM 0,R14.  It will do the right thing in every case you
mentioned.

As you didn't originally specify much of this, we had to qualify answers
with various unlikely scenarios.  Fact is, BSM 0,R14 works correctly for
any call by BASSM, BSM, BASR, BAS, JAS (BRAS), JASL (BRASL), BALR, and BAL
(BAL only in 31-bit mode).

The "special" cases, especially when R14 is loaded up separately, are
unpredictable.  Fortunately, those are rare, and slightly rarer coded
incompetently, such that R14 has the wrong AMODE indicator. Your list of
requirements do not say you need to support any of those.

Furthermore, your program can switch AMODE all it likes.  The BSM 0,R14
will restore the correct AMODE on return to the caller.  And I don't see
that LE is relevant.

Seems like a case of over-thinking and under-learning.

sas


On Fri, Aug 14, 2020 at 6:23 PM Tony Thigpen  wrote:

> I have been reading all the "that is not a good way to do it" posts, so
> here it the challenge to all those nay-sayers.
>
> It's time to 'put-up' or 'shut-up'.
>
>

Re: how to return?

[Steve Smith]

The goal should be to return to the caller in its amode, as that's
undoubtedly what it expects.

If a program is invoked via BASSM (or BSM), the amode in effect at entry is
NOT the caller's amode, other than by chance.  So if you save the amode at
your entry, and use that for return, you will likely cause an abend or
worse.

This is the end of my tutorial on basic linkage.  This is all
well-documented in the Principles of Operation, and Assembler Services
Guide Chapter 5.

sas


On Wed, Aug 12, 2020 at 3:25 PM Gary Weinhold  wrote:

> That was my point; If the goal is to allow the called program to switch
> to amode 31 and return to the caller in the amode it was in, it appears
> Binjamin's 2 instructions are sufficient.  The original code is checking
> to see if they need to do this (and there is a small exposure because
> the opcodes could be spoofed or EXECed, as others pointed out, or the
> locations preceding the R14 could be unaddressable), and it may be more
> efficient to just run the LA and BSM without checking.  Tony mentioned
> that the code is now used outside its original controlled environment,
> so the assumptions abut how it's  entered may no longer apply.
>
> My comment on speed was checking the opcodes and branching take some
> cycles and the LA, BSM instructions may take fewer.
>
> On 2020-08-12 2:04 p.m., Martin Truebner wrote:
> > Gary,
> >
> >>> Are we to conclude from that this discussion that this is a reliable
> way
> >>> to ensure that an AMODE 31 subroutine returns control to its caller
> >>> in the correct amode?
> > the code Tony had was to ensure that it can switch to whatever mode
> > a routine to be called from that code needs
> > without effecting the original caller of the code
> >
> >>>  From Binjamin's response, it appears that checking the opcode of the
> >>> previous instruction was unnecessary and perhaps, depending on the
> >>> speed of BSM, actually slowed down the routine.
> > no no - if BSM is needed (because original caller of the code is 24
> > and final target is 31) then Binjamin's code is fine (at entry!) ...
> >
> > but it also is executed if everyone is 24 and there is no need for it.
>
>
>
> Gary Weinhold
> Senior Application Architect
> DATAKINETICS | Data Performance & Optimization
> Phone:+1.613.523.5500 x216
> Email: weinh...@dkl.com
> Visit us online at www.DKL.com
> E-mail Notification: The information contained in this email and any
> attachments is confidential and may be subject to copyright or other
> intellectual property protection. If you are not the intended recipient,
> you are not authorized to use or disclose this information, and we request
> that you notify us by reply mail or telephone and delete the original
> message from your mail system.
>

Re: how to return?

[Steve Smith]

Absolutely not.  Binyamin qualified his answer with "... where the mode you
wish to return in is the same at entry to the routine."  When called by
BASSM, that is not the case.

The OP's code was to solve a particular problem with a particular program.
Nothing about it should be taken as good for anything.

sas

On Wed, Aug 12, 2020 at 12:33 PM Gary Weinhold  wrote:

> Are we to conclude from that this discussion that this is a reliable way
> to ensure that an AMODE 31 subroutine returns control to its caller in
> the correct amode?
>
>

Re: Clearing a register

[Steve Smith]

For the whole register, LGHI, LLILL (or HL, LH, or HH) are best.  LLILF,
LLIHF take up more space.  XGR, SGR, SLGR set the CC.

For only the low half, XR, SR, SLR have the shortness advantage, and LHI
the non-CC advantage.

Chances are that the CC setting is irrelevant in timing on modern CPUs.

The worst way to zero a register is more interesting.  JCTG Rx,* is my
favorite.  If Rx is already 0, guess how long that will take.

sas


On Mon, Aug 10, 2020 at 8:24 PM Dan Greiner  wrote:

> Several recent z Models include a feature that recognizes some
> instructions that zero a register (or portion thereof) and bypass certain
> pipeline stages for faster execution. I don't recall which models or which
> instructions, but LHI, LGHI, SR, SGR, XR, and XGR seem to ring a bell.
>
> If this question is more than just an academic curiosity, then you will
> have to seriously consider how frequently the register-clearing code will
> be executed ... and will you EVER recoup the cycles spent re-assembling and
> testing the updated code.
>
> As to LA and LAY, recall that the results of these instructions are
> dependent on addressing mode, and they will not zero bits 0:31 of the
> register in AMODE 24 or 31.
>
> The main consideration that I used in picking the which instruction to use
> was code size  — knocking myself silly trying to keep frequently-executed
> code within the same page ... if not within the same cache line — so SR and
> XR were preferred. A secondary consideration was whether I needed to
> preserve a previously-set condition code — so LHI and LGHI were preferred.
>

Re: Clearing a register

[Steve Smith]

The only difference between SR & SLR is how they set the condition code.
If that could produce a measurable difference in a trillion executions, I'd
love to see it.

sas

On Mon, Aug 10, 2020 at 5:49 PM Gary Weinhold  wrote:

> it may go back to the idea that SR might require an extra step to
> set/propagate the sign while SLR wouldn't.  But I don't know if that
> actually ever made a timing difference on any machine.
>
>

Re: Clearing a register

[Steve Smith]

I wish IBM would add the LZR instruction just so this question could stop
being asked.

sas

Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)

[Steve Smith]

My discussion was about the architecture.  The fact that it wasn't
supported by the OSes of the day may be true, but that doesn't mean it was
"prevented", or *couldn't* be used.  If customers thought it was useful,
they could have asked IBM to support it, or implemented it themselves.  The
salient fact, according to the article, is that no one ever did.

I'm aware that -0 means first edition in IBM manual numbering, but they
occasionally change the manual number and start over.  Anyway, it appeared
to be the oldest one on bitsavers, which is where I got it.

sas

Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)

[Steve Smith]

Sheesh... I missed it somehow, but it is in there.  ED & EDMK did support
ASCII mode, and used x'3x' zones in that case.

This old, possibly original (it has no date), Principles of Operation was a
whopping 168 pages.  But I haven't read the whole thing :-).  ED & EDMK are
listed in the "Logical Operations" section, whereas PACK & UNPK are in the
"Decimal Arithmetic" section.  You know which pair can cause a S0C7 though.

sas


On Sat, Aug 8, 2020 at 9:29 PM Charles Mills  wrote:

> ED was not part of the original S/360 instruction set? Did you look under
> Decimal Instructions?
>
> Charles
>
>

Re: Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)

[Steve Smith]

The ASCII feature of S/360 probably wasn't used because it's nearly
useless.  Turning on ASCII mode caused PACK & CVD to generate ASCII sign
codes and UNPK to generate ASCII zone codes.  As far as I can tell, that's
it.  I'd say that the much later PKA & UNPKA instructions make a lot more
sense than a system option, so I suppose somebody thinks the function is
useful.  But you could always convert zoned decimal with NC/OC or, of
course TR.

ED isn't in my very old S/360 PoOp (A22-6821-0), but ED certainly came out
soon, long before the ASCII bit was officially dropped.  Anyway, I don't
know whether it supported ASCII mode or not.

sas

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

[Steve Smith]

 Something that I'd like to see inPoOps is an example of using UNPK
and TR to convert binary to hexadecimal.

You can't "convert" binary to hexadecimal, their bit patterns are the
same.  If you're referring to displaying bytes' hexadecimal representation
in EBCDIC, then I'd say it's a bit late for that.

Thanks to a tip from Rob Scott on this list several years ago, I like using
TROT, especially when writing out a considerable amount of storage, like a
dump.  The TROT table starts thus:

DC C'000102030405060708090A0B0C0D0E0F'
... and continues for the obvious 15 more lines.


sas

Re: z/OS HLASM: EQU for statement labels

[Steve Smith]

Actually, no, no one needed to ask.  This is a technical discussion board,
and airing one's opinions about others' demeanor or perceived attitude are
completely out-of-line and a waste of bandwidth and every subscriber's time.

Everyone has opinions about the denizens of this list.  There are a few
regular posters that I routinely delete w/o reading.  And I may be on
others' plunk list.  But this forum will be useless if it is clogged up
with harping on each others' manners.  We can figure that out individually;
and ignore perceived slights from people we do not know.

sas

> > Somebody has to ask: Shmuel, why are you such a hostile prick? The
> > smugness
> > > and lack of comity you exhibit are at odds with the general tenor of
> this
> > > forum, and your comments--while sometimes useful--are so often just
> > showing
> > > off and being difficult that, were I the list owner, I'd have you on
> > > moderation or banned.
> > >
> > > Seriously: what is the point of being such a jerk all the time? What
> > > purpose does it serve you?
> > >
>
>

Re: z/OS HLASM: EQU for statement labels

[Steve Smith]

Not bad.  It's very useful for assembler programmers to understand the math
behind 2s-complement (and how it nicely "complements" wrap-around
addressing) thoroughly enough to get that; besides understanding you
avoided changing the CC.

But for the record, that's a negative value in an index register.

sas

On Tue, Jun 2, 2020 at 4:24 PM Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> On 2020-06-02, at 14:01:28, MELVYN MALTZ wrote:
> >
> > Labels...
> > Even back in the 60's I was taught never to put a label on an instruction
> > I only break that rule now for the subject of an EX (and its variants)
> >
> It's safer than
> labelEQU   *
>
> > Returning CC from a subroutine...
> > Have to point out that IBM do this in the VSAM TESTCB macro
> >
> I had one co-worker who insisted on doing that.  He augmented
> our MVS/XA common return macro to:
>
>  IPM
>  ...
>  SHR13,=Y(workarea_length)
>  ...
>  SPM   , restore CC
>
> then *I* was tasked with porting to VM/370.  No IPM.  I did:
>  LH   R1,=Y(-workarea_length)
>  LA   R13,0(R1,R13)
>
> I had a tough time in code review.  Reviewers called me
> naive for using a negative value in a base register.  No,
> the were ignorant; the code worked and was correct.
>
> -- gil
>

Re: *-*

[Steve Smith]

Why do you beat your wife?  ;-)

Show me an error it catches, and I'll answer.

sas

On Thu, Apr 30, 2020 at 5:59 PM Seymour J Metz  wrote:

> Why is a feature that helps the assembler catch some errors at assembly
> time not useful?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>

Re: *-*

[Steve Smith]

Primarily, I don't think distinguishing 32-bit and 64-bit versions of the
general registers is all that useful.  If your program is using 64-bit
registers, then hopefully it plans on restoring them for its caller.
Beyond that, what's the point?

sas


On Thu, Apr 30, 2020 at 2:56 PM Seymour J Metz  wrote:

> > GR64 (which I highly nonrecommend)
>
> Why?
>
>

Re: *-*

[Steve Smith]

HLASM does indeed have register types:
R10  EQU   10GR (or AR, FPR, GR64 (which I highly nonrecommend))

The "assembler type" (iirc) is an accessible attribute.

sas

On Thu, Apr 30, 2020 at 12:09 PM Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:

> ...
>
> Doesn't HLASM have a register symbol type?  Could macros
> rely on this rather than parentheses to indicate registers?
>
> -- gil
>

Re: Does S0C5 still exist ?

[Steve Smith]

I created a better one, based on LURA, and tests fine.  You don't get an
exotic PSW, but this will abend with a S0C5, with no risk to the system:

IEFS0C5  START 0
IEFS0C5  RMODE ANY
IEFS0C5  AMODE 64
 MODESET MODE=SUP
 LLIHH 2,X'DEAD'
 LURA  1,2
 BR14
 END

... it will not get to the BR 14, so it's superfluous.

APF authorization is required. IF there's a way to incur a S0C5 in problem
state, I don't know it.

sas


On Thu, Jan 30, 2020 at 3:51 PM MELVYN MALTZ <
072265160664-dmarc-requ...@listserv.uga.edu> wrote:

> Hi Steve,
>
> You're the only person to actually meet my request...thankyou
> I would much appreciate the code used, I tried B and MVI to your address
> in
> A/RMODE 31 but I get S0C4
>
> Melvyn.

Re: Does S0C5 still exist ?

[Steve Smith]

Well, Dave, how long have you been watching IBM-MAIN?  Guesses,
speculation, "feelings", and irrelevant musings are what this forum does.

Obviously there is some valuable and correct information, and one can only
hope that those who need correct advice can sort it out.

On this thread, I've ignored the ignorant posts that could be cured by
RTFM, and tried reinforcing the valid answers with some facts (and btw, I'm
always open to correction or clarification when needed).  These posts
appear to have been ignored.

The logical conclusion is that it's useless to try.

sas



On Thu, Jan 30, 2020 at 7:04 AM David Cole  wrote:

> Wow! While Keith, John and Kevin here are among the few giving
> correct and useful answers...
>
> I'm dismayed by the number of responders whose "answers" are just
> pulled out of their butts!
> Come on Guys! You don't have to guess or speculate on something that
> is so simple to look up.
> I mean... why answer at all when you know you don't know???
>
> Dave Cole