Tom,
I have reread and reread it. If what Michael seems to be saying is true,
then your charts are wrong. But(!), I think your charts are right and
Michael's wording is giving me problems. I thought I had this all worked
out until Michael's 1/31/22, 16:37 (EST) post where he said:
"I put
One other option that generates a few bytes less code:
IC 1,BYTE
RISBGZ 0,1,54,55,2
RISBGZ 1,1,62,63,-4
OR 0,1
AHI 0,C'11'
This puts the results in the rightmost two bytes of general register 0.
MVS has that; it's called step restart.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Tuesday, February 1,
What happened to TLBL?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Bernd Oppolzer [bernd.oppol...@t-online.de]
Sent: Tuesday, February 1, 2022 7:29 PM
To:
And, BTW, the DD statement is called "DLBL" in VSE.
And yes, it is coded before the EXEC statement.
Kind regards
Bernd
Am 02.02.2022 um 01:25 schrieb Bernd Oppolzer:
Am 01.02.2022 um 23:36 schrieb Paul Gilmartin:
On Feb 1, 2022, at 14:47:15, Tony Thigpen wrote:
...
VSE has had JCL
Am 01.02.2022 um 23:36 schrieb Paul Gilmartin:
On Feb 1, 2022, at 14:47:15, Tony Thigpen wrote:
...
VSE has had JCL "GOTO" since "whenever", but JES2 did not have it for a long
time.
Perhaps not even yet. I can't find GOTO in the JCL Ref. What JES2 manual
should
I search. Can you
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
On Feb 1, 2022, at 14:47:15, Tony Thigpen wrote:
> ...
> VSE has had JCL "GOTO" since "whenever", but JES2 did not have it for a long
> time.
>
Perhaps not even yet. I can't find GOTO in the JCL Ref. What JES2 manual
should
I search. Can you code loops with it?
> ... (And don't get
RXVSAM can be found at https://www.cbttape.org/ file 268.
RXVSAMBA, which does I/O to/from VSAM by REXX stems, can be found at
https://www.cbttape.org/ file 669.
Willy
-Oprindelig meddelelse-
Fra: IBM Mainframe Assembler List På vegne af
Farley, Peter x23353
Sendt: 1. februar 2022
On Mon, 31 Jan 2022 17:02:37 -0500, Tony Thigpen wrote:
>Michael,
>
>Again, bear with me. I am trying to wrap my head around this stuff.
>
>On your last point about using F7SA for a 144 byte save area. You
>said you put F7SA in the 144 byte area because the previous save
>area was a 216 bytes
I realized I didn't need the fourth STCM so now the code is as
follows. It may be strange, but keep in mind that the output date content
of R14 and R15 is already in character format (MMDD YYCC) and the output
time content of R1 is already in packed format (0hhmmssC). I know
Not on a 2818 (that is a z114 box if my google-fu is correct). Vector Packed
Decimal is much more recent, z14 and up I think. The Vector Packed Decimal
instructions were introduced in the 2017 PoOP, edition "-11" (12th edition).
There are Vector instructions available on a z114, just not the
VSAM IO for VSE/REXX is an IBM item.
VSE REXX has a few things that z/OS does not. It's come up in the past,
I just can't remember the details.
VSE also had NJE over IP a long time before z/OS.
VSAM shareoption-4 really works correctly in VSE but was never fully
implemented in z/OS. (I long
On Mon, 31 Jan 2022 16:19:23 -0500, Tony Thigpen wrote:
>a) If it's FxSA, then the forward/backward pointers are at x80-x8F,
>thus we can safety STMG R14,R12,8(R13) because that area is before
>the forward/backward pointers. We also know that we can store a
>new forward pointer at x88.
What
"IBM Mainframe Assembler List" wrote on
02/01/2022 04:33:56 PM:
> Not that they don't work as is, but I wonder if those STCM's and
> UNPK could be replaced by Vector Packed Decimal instructions
> (assuming you have hardware that supports them)
Yes, GETIME returns the date in what I
You're welcome. I'm lucky I even remembered the macro name, as I haven't
worked on any VSE system since 1994. I did google current IBM VSE GETIME doc
but misremembered input regs vs output regs between lookup and email writing.
PEBKAC.
Not that they don't work as is, but I wonder if those
"IBM Mainframe Assembler List" wrote on
02/01/2022 12:29:45 PM:
> Perhaps the following helps?
>
> LM 14,15,64-bit-time-storage-area
> GETIME STANDARD,LOCAL,CLOCK=YES
Yes, that helped big time. Thank you very much. Your LM should
be for R0 and R1, though. I used the following
RXVSAM at below link I believe provides that for z/OS and possibly z/VM, not
sure about z/VM though.
https://sourceforge.net/projects/rxvsam/files/
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Schmitt, Michael
Sent: Tuesday, February 1, 2022 3:59 PM
To:
We have the REXX Catalog Search Interface (CSI), via IGGCSI00. But we can't do
VSAM I/O from REXX, using standard out-of-the-box TSO. There's probably
something in SHARE. Or vendor products.
As far as I know.
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Dave
"IBM Mainframe Assembler List" wrote on
02/01/2022 03:42:51 PM:
> > The external assembler REXX function I am working on is so that I
> don't have to depend upon the built-in REXX VSAMIO function.
>
> Why does VSE get VSAMIO but MVS doesn't?
>
> I could understand if REXX in VM was more
> The external assembler REXX function I am working on is so that I
don't have to depend upon the built-in REXX VSAMIO function.
Why does VSE get VSAMIO but MVS doesn't?
I could understand if REXX in VM was more advanced, but VSE??
-Original Message-
From: IBM Mainframe Assembler List
reation Date */
RPRTDBS._EXPD = 20220123 /* Expiration Date */
RPRTDBS._TSTP = 20220201 030354 /* Last Update Date/Time */
RPRTDBS._SHRO = 4 3 /* Share Options */
RPRTDBS._DATA = DAPSCO.REPORT.DATABASE.DATA
RPRTDBS._DCSZ = 26624/* DATA CI Size */
RPRTDBS._DE
Perhaps the following helps?
LM 14,15,64-bit-time-storage-area
GETIME STANDARD,LOCAL,CLOCK=YES
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Dave Clark
Sent: Tuesday, February 1, 2022 12:14 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Unsigned 64-bit
No sexy instructions, but this code provides the output characters
complete with a space, and uses only one register:
LLC 1,BYTE
SRL 1,4
MHI 1,3
LA 1,TABLE(1)
MVC RESULT,0(1)
TABLE DC C'1 11 21 31 42 12 22 32 43 13 23 33 44 14 24 34
"IBM Mainframe Assembler List" wrote on
02/01/2022 11:50:07 AM:
> You may want to investigate the STCKCONV macro.
Not available on z/VSE. Thanks.
Sincerely,
Dave Clark
--
Winsupply Group Services
3110 Kettering Boulevard
Dayton, Ohio 45439 USA
(937) 294-5331
You may want to investigate the STCKCONV macro.
HTH
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Dave Clark
Sent: Tuesday, February 1, 2022 11:39 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Unsigned 64-bit numbers
I previously asked about
On Feb 1, 2022, at 09:38:58, Dave Clark wrote:
>
>I previously asked about 32-bit unsigned numbers and that opened
> up some new instructions (new to me, anyway: LLGF, LLGH, etc) for loading
> unsigned numbers into registers. But now I have need to load a 64-bit
> unsigned value into
"IBM Mainframe Assembler List" wrote on
02/01/2022 11:42:56 AM:
> This is just a LG, just like L for 32-bits. It doesn't matter
> whether it's signed or unsigned. There's nowhere for a sign to be
extended.
Ah, I see. Got it. Thanks.
Sincerely,
Dave Clark
--
int.ext: 91078
This is just a LG, just like L for 32-bits. It doesn't matter whether it's
signed or unsigned. There's nowhere for a sign to be extended.
Robert Ngan
DXC Luxoft
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Dave Clark
Sent: Tuesday, February 1, 2022 10:39
To:
I previously asked about 32-bit unsigned numbers and that opened
up some new instructions (new to me, anyway: LLGF, LLGH, etc) for loading
unsigned numbers into registers. But now I have need to load a 64-bit
unsigned value into a register and I don't see an LLGD instruction for
that.
"IBM Mainframe Assembler List" wrote on
02/01/2022 04:40:19 AM:
> To be fair we have to consider that Dave stored the results
That's correct. but, I wasn't storing the two values next to each
other. I left a space in between. So you need two instructions to store
the results
Peter F wrote:
. . . each save area indicates how the BACKCHAIN POINTER WAS (not
"registers were") stored by the program that created that area.
No, it indicates BOTH how the backchain pointer was stored *and* also how
the caller's registers were stored.
When you create a save area, it is
It'd s typo for ALFI, on p. 7-29 of the -12 PoOps.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Martin Trübner [mar...@pi-sysprog.de]
Sent: Tuesday, February
AHI takes a signed operand. You could use ALFI, but that's 2 bytes longer. Is a
quote (") valid for framing constants? SC26-4940-06 only lists apostrophes.
What is the URL for the most recent edition?
I've submitted an RCF asking for clarification of the syntax of self-defining
terms.
--
Tony,
sorry - I did not read to the end.
Yours is the shortest (24 bytes - all should have new machines)
But the table is pretty long
Martin
Ref: Your note of Tue, 1 Feb 2022 10:40:19 +0100
Martin Truebner writes:
>
> LLC R0,BYTE
> SRDL R0,6
> SRL R1,6
> SLDL R0,8
> AHI R0,C"11"
> STH R0,RESULT
>
> But HLASM complains:
> ** ASMA320W Immediate field operand may have incorrect sign or magnitude
>
> only a sev 4
That's because C'11'
To be fair we have to consider that Dave stored the results
So:
Dave had 38 with storing results
Dan is IMHO 32 with storing results
Mine is 26 with storing results
LLC R0,BYTE
SRDL R0,6
SRL R1,6
SLDL R0,8
AHI R0,C"11"
STH R0,RESULT
But HLASM complains:
** ASMA320W Immediate field
37 matches
Mail list logo
