You left out the second DC statement so I put one in for you. Here is an
assembly:
Active Usings: None
Loc Object CodeAddr1 Addr2 Stmt Source Statement
There were already logical instructions as early as the 360 machine series.
However, early COBOL compilers (and even up to Enterprise V4) implemented the
COBOL standard for numeric values by converting unsigned binary values to
packed decimal and zeroing out any integer digits left of 4 digits
Not if the code is executing in a getmained area. I've often put code in such
areas for various reasons (e.g. OPEN exits, I/O error exits. etc.), and it's
annoying to have to set up base registers.
But I confess I think an "MVCRL" instruction where *both* source and
destination are relative
..
On Mon, May 9, 2022, 10:34 Farley, Peter x23353 <
0dc9d8785c29-dmarc-requ...@listserv.uga.edu> wrote:
> However, still not available yet for those of us without a Resource
> Link ID. I assume we will gain access at GA at the end of this month.
>
> Peter
>
>
However, still not available yet for those of us without a Resource Link ID. I
assume we will gain access at GA at the end of this month.
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Don Higgins
Sent: Monday, May 9, 2022 6:19 AM
To:
I believe that SA22-7832-12 is the z15 edition. AFAIK the z16 edition is not
yet available. Others have pointed out that the next PoOP isn't usually made
available until GA of the hardware, which is said to be May 31, 2022 for z16.
So it should be available in about 6 weeks, give or take a
I would absolutely prefer POSIX ERE, with which I have many years of experience
via gawk programming. I am not comfortable with PCRE at all.
+1 for the back-reference assignments.
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Paul Gilmartin
Sent: Tuesday,
An interesting question. Isn't ". . . call a subroutine . . . " more generic,
so just "subroutine call instructions" or "program linkage instructions" (that
one is less clear to me) for the title of that overall group of instructions?
You left out BAKR and PC from your list. Aren't they
I am not having that problem here, but I do have a similar issue on the
TSO-REXX list. I've checked and double-checked my listserv settings there and
I do have REPRO and the other option to receive copies of my own posts (I
forget the name now), but I still have issues posting there.
I even
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
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
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:
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
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
If I have understood this thread at all, then a slight correction to you last
sentence is in order:
. . . each save area indicates how the BACKCHAIN POINTER WAS (not "registers
were") stored by the program that created that area.
When you create a save area, it is for your callees to use to
Gil, that is clever as all get out. Thanks for the idea, though I don't have
any immediate use for it myself. That's one to file in the ASM tools bag,
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Paul Gilmartin
Sent: Monday, January 31, 2022 2:52 PM
To:
Especially since in z/OS it is now documented to pass a 144-byte save area to
the step-level "PGM=" executable. AFAIK, what size save area either the online
TMP or the batch TMP's (IKJEFTxx, IRXJCL) pass to Rexx is not documented.
I don’t know what z/VSE documents as the program-level save
Dave, if speed is an issue (i.e., your small routine is called many, many
times), BAKR is **SLOW** even on very recent hardware. It is convenient, but
normal save/restore processes beat the pants off BAKR if execution time is
critical.
Considering also the traceability issue and the task
Note in that manual on page 34 of that PDF (page 6 in the book) it says:
When a program receives control as the target of the EXEC statement,
general-purpose register 13
contains the address of a 144 bytes save area, which is provided by the system.
The system starts out your batch program with
At program entry:
STMH 2,14,your-high-halves-save-area13 fullwords for 2-14 high halves
At program exit:
LMH 2,14, your-high-halves-save-area
HTH
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Dave Clark
Sent: Wednesday, January 19, 2022 5:21 PM
To:
That is correct. All GP registers are actually 64 bits wide and 32-bit
instructions use the lower half only.
To use all 64 bits use the "Grande" version of the 32-bit instructions (most
are suffixed with "G"). There are also instructions that affect only the upper
32-bit halves of the GP
one line of the code.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Sunday, January 2, 2022 12:31 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: ADATA dump utility [was: RE: Determining
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
Peter R. may answer on his own, but my impression is that this VR/FPR overlap
is part of the hardware chip design of the FPU part of the z chips, and the
fact that the zarch SIMD VR instruction functionality was (probably) initially
aimed at mathematical computations that need FPU operations.
Re-sent considerably trimmed due to IBM-MAIN restriction of 250 lines per reply.
-Original Message-
From: Farley, Peter x23353
Sent: Tuesday, December 7, 2021 6:36 PM
To: IBM Mainframe Assembler List
Subject: RE: Is it possible to update CSA from an unauthorized user-key program
security requirements of some commercial mainframe environments, I suspect most
ISVs would not see a sufficient market to provide a narrower solution at an
acceptable cost to potential customers.
On 2021-12-07 12:20 a.m., Farley, Peter x23353 wrote:
>
> I don't know about anyone else, bu
I don't know about anyone else, but I am really getting tired of these
continuous calls from supposedly knowledgeable people to "invent your own PC or
SVC to protect your global shared storage application solution and don’t trust
anyone or anything and if you do this your integrity is your own
And IIRC in ancient days the PL1 runtime used to use word 1 of the RSA for its
own purposes. Don’t know if LE and Enterprise PL1 (or Enterprise COBOL for
that matter) continued that tradition or not.
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Mark
Beware of current and future compiler technology (especially COBOL 5/6+ and
PL/1 in recent incarnations) that is beginning to use the string and decimal
vector operations and vector operations in general, all of which can use any of
the FPR's.
E.G., your COBOL caller may not define or use any
No need for a resource link id - Thanks to Jim Elliot (retired IBMer) most PoOP
manuals can be retrieved by starting here:
https://jlelliotton.blogspot.com/p/cmos-processor-table.html
HTH
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Laddie Hanus
Sent:
Gil,
When you say "not Linux", which list would that be? I'm subscribed to MVS-OE
but that list is very low traffic (last message I received there was from May
2021).
Is there a separate z/Linux list somewhere?
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Where did you get the TBIT macro? I'm not familiar with it. Can you share the
macro source, or tell us where it came from?
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of João Reginato
Sent: Thursday, May 20, 2021 11:15 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Thanks for the heads-up Jean.
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Jean Snow
Sent: Wednesday, May 19, 2021 8:28 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: UGA Listserv Upgrade Friday May 21
UGA is going to be upgrading our Listserv service to a
I stand corrected. I missed the OP's specification (in the subject as well as
in the text) of loading EXTERNAL addresses via IILF. EXTERNAL relative adcons
do indeed require GOFF.
My uses of LARL to date have all been for in-the-current-CSECT locations.
Peter
-Original Message-
LARL does NOT require GOFF format assembler output. I have many assembler
subroutines using LARL that generate normal 360/370/390 object records and
linked into PDS's (not PDSE's).
There are assembler features that require GOFF format, but not LARL on its own.
Peter
-Original
Because most hackers who want to insert malicious code into a web page don’t
know mainframe object code but do know how to insert arbitrary Intel object
code and java byte code and SQL to achieve their ends.
Maybe also because there are probably very few mainframe ALC programs that are
It is not necessary to getmain storage in which to run a dynamically created
program. I wrote a simple subroutine to retrieve the LE CAA address from R12
that can be stored in a COBOL WORKING-STORAGE area and executed very easily.
Sample code below.
You could copy this simple subroutine into
.
>
> Chris Blaicher
> Technical Architect
> Precisely.com
>
>
> -Original Message-
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353
> Sent: Monday, October 26, 2020 2:33 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.
Isn't that true only if the dynamically built instruction isn't in the same
cache line as the code that performs the build and EX?
I've seen examples where the "built" instruction was a non-reentrant location
in the same CSECT and very near to the "build" instructions. Not my code, but
I have
I don't know how today's machines (z13 and up) perform, but back when I had
access to Strobe it regularly pointed out long MVCL / CLCL instructions
generated by COBOL 4.2 (in the specific application case I was working on these
were usually around 8K bytes) as relatively large "hot spots" of
True, but my understanding is that BAKR is quite slow compared to normal save
area chaining processes, especially for frequently-used subroutines.
I could be wrong about that, and obviously as the hardware changes IBM can
improve the performance of BAKR, but that was the last advice concerning
A not unreasonable solution is to create a 144-byte save area for your own
subroutine and calls you will make (or at least 72 bytes larger than whatever
kind of save area you are setting up for subroutines that you will call) and
save / restore the caller's high-halves at entry and exit of
I believe that an ESPIE(X) will capture the "compare-and-trap-instruction data
exception", but a much better solution would be if z/OS supported the efficient
setting of a TRAP exit routine to get control on a trap condition rather than
having to generate an interrupt exception. Unfortunately
Too clever by far. Offhand I don't think I would give it a passing grade in a
code review.
I can't immediately think of situations where it might fail, but I have the
sneaking suspicion that what I don't know (and that's a lot) could bite that
code.
Peter
-Original Message-
From:
Mainframe Assembler List On Behalf
Of Ed Jaffe
Sent: Sunday, June 7, 2020 6:24 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Does the z architecture have something like the SIMD instructions
On 6/7/2020 9:23 AM, Farley, Peter x23353 wrote:
> Is there any chance you could provide (maybe eventua
Ed,
Is there any chance you could provide (maybe eventually in a SHARE session
presentation?) a set of good examples of using the vector instructions as you
say you do?
Or am I late to the party and there have already been such SHARE sessions that
I missed?
If I have one particular beef with
I got out of the habit of using EQU * for labels long ago due to an
assembler-level debugger (I don't remember which one now) that didn't recognize
EQU labels but did recognize DS 0H labels.
I have always avoided directly labelling procedural statements for the same
reason you did - one less
PoOP and PoOPs here. Used to use just POP or POPs but not in recent decades..
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Phil Smith III
Sent: Monday, September 16, 2019 3:50 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Poll
Principles of Operation-how
Thanks for that link.
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Dale R. Smith
Sent: Friday, September 13, 2019 11:55 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: z15 is announced…
On Fri, 13 Sep 2019 09:19:08 -0400, Tom Russell
wrote:
>> I'm
Once you get the coding correct, any R15 value not zero from DEVTYPE can be
treated as "DD not found". Simplest solution and solid as a rock to use.
HTH
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Richard Kuebbing
Sent: Wednesday, July 24, 2019 1:25 PM
FREEPOOL the buffers after CLOSE? Maybe use a DECB with RMODE31=ALL to get the
control blocks and buffers above the line?
You may just be running out of below-the-line (16M) memory.
HTH
Peter
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Phil Smith III
Sent:
LARL is no help if it is truly an external (not in the current source) program
or entry point.
If it really external, your 3 lines are the only way I can see to do it so that
the VCON is in the second word of the instruction.
Or with a macro that does the 3 lines for you.
And yes, LLILF is a
<*Doh!*> Sorry, never mind. I see other entries in the thread in this forum.
Apologies.
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Thursday, May 16, 2019 10:23 AM
To: ASSEMBLE
PMFJI here, but can you tell us where the rest of this conversation may be
located? I found only one message on IBM-MAIN with this subject, from April
22, author Joe Reichmann.
I would be interested to read the whole thread if I could find it.
Peter
-Original Message-
From: IBM
I disagree here. It is not "concealing it in HLASM" to know what line number
of what COPY/MACRO member of what DSN generated the error. HLASM knows that
information and only needs to send it out in its failure message. DFSMS knows
nothing of how or why HLASM reads its inputs, only HLASM
Jonathan,
Possibly not a " sensible use of development resources", but that is an IBM
decision I guess. I would say instead that a SYNAD exit on READ/GET from SYSIN
and SYSLIB are in fact sensible uses of development resources rather than
letting a generic SYNAD condition abend the assembly
As opposed to the Scots instruction set, MC'opcode?
That was a good chuckle, thanks for making my morning brighter!
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Rob van der Heij
Sent: Wednesday, April 3, 2019 6:40 AM
PoOPS for SRST (edition -9, which is for the zBC12) says this:
"The character for which the search occurs is specified
in bit positions 56-63 of general register 0. Bit
positions 32-55 of general register 0 are reserved for
possible future extensions and must contain all
zeros; otherwise, a
Ed,
That sounds like a great topic for a SHARE presentation on advanced assembler
usage, if it's not considered too proprietary to release into the wild.
Any chance of that happening?
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
quot;char[8]". I haven't exercised CDSECT
V2.2 yet, it will be interesting to see what it does with those kind of
definitions.
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Tuesday,
Indeed, that is true. And it is even possible (and not terribly hard) to
automate a process to "massage" the CDSECT output to make it far more palatable
and sensible (e.g., define known address variables as A or AD as needed, add
__PTR32 or __PTR64 where needed, and even fix "bugs" in the
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Count Words?
EXTERNAL EMAIL
On 2018-06-16, at 18:53:32, Farley, Peter x23353 wrote:
>
> The PoP says for the Vector String instructions that "For all instructions
> that optionally set the condition code, performance may be degraded if th
case?
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Ed Jaffe
Sent: Saturday, June 16, 2018 9:23 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Count Words?
On 6/16/2018 5:53 PM, Farley, Peter x23353 wrote:
> The
Ed,
The PoP says for the Vector String instructions that "For all instructions that
optionally set the condition code, performance may be degraded if the condition
code is set."
Have you found that performance can be significantly (or at all) improved by
not setting the CC in the SIMD
Gil,
I think you read the wrong PoP instruction description. Ed used VFAEB not
VFEEB, and for VFAE the corresponding description is (*** emphasis mine):
Proceeding from left to right, each element of the
second operand is compared for equality with ***every***
element of the third operand.
As
Thank you!
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Ed Jaffe
Sent: Thursday, June 14, 2018 6:06 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Count Words?
On 6/14/2018 1:50 PM, Farley, Peter x23353 wrote
Any way you could share a code example? Or at least pseudo code for the
technique?
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Ed Jaffe
Sent: Thursday, June 14, 2018 3:34 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
.
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Thursday, June 14, 2018 4:17 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Count Words?
One could reverse engineer the XLC/C++ library module
One could reverse engineer the XLC/C++ library module for strtok() using your
local assembler debugger . . . just to see how it's done, mind you.
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Charles Mills
Sent:
I think I read somewhere that is what keyed VSAM Index records are, aren't
they? A count of equal key bytes and then the remaining non-equal bytes,
followed by the RBA in the data component? Or is that a fib I was told?
Peter
-Original Message-
From: IBM Mainframe Assembler List
I am very sad to hear that news. Dr. Ehrman was a great help to all of us here
and a true gentleman.
May he reset in peace.
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Dan Greiner
Sent: Tuesday, February 20, 2018
Given the age of the compiler code (he did say MFT), they might be from the
JESx predecessor product, HASP.
HTH
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Keven
Sent: Friday, February 16, 2018 7:56 PM
To:
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Thursday, February 1, 2018 12:02 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Pu
EXTERNAL EMAIL
I replied to this thread over on IBM-MAIN, not realizing
I replied to this thread over on IBM-MAIN, not realizing that it originated
from this list, but here is a copy if my reply for the archives:
There appear to be pretty stable PoOP links on Jim Elliot's CMOS Processor page:
https://jlelliotton.blogspot.ca/p/cmos-processor-table.html
HTH
Peter
24, 2017 2:17 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Dynalloc (was Macro processor)
EXTERNAL: This email originated from outside of Broadridge. Do not click any
links or open any attachments unless you trust the sender and know the content
is safe.
On 2017-12-24, at 11:01:38, Far
.
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Paul Gilmartin
Sent: Sunday, December 24, 2017 9:33 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Dynalloc (was Macro processor)
On 2017-12-24, at 00:10:58, Farley, Peter
Jon,
Dynalloc is not an exposure in a properly configured z/OS SAF environment.
Most large shops I have worked at don't allow application programmers (who are
the ones most likely to have the skills to perpetrate a security breach and the
necessary inside knowledge of process and procedure)
Apologies, I accidentally sent this reply so Jon directly instead of to the
list.
Peter
-Original Message-
From: Farley, Peter x23353
Sent: Friday, December 22, 2017 7:34 PM
To: 'Jon Perryman'
Subject: RE: Dynalloc (was Macro processor)
Jon,
I think our confusion (or at least my
That is terrific news! Thank you!
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of David Staudacher
Sent: Friday, December 22, 2017 8:55 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Calling BPXWDYN to Return DSNAME
.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Wednesday, December 13, 2017 8:08 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Address of a =LITERAL
This is really a simple proble
This is really a simple problem to solve. Here is a sample "data" program that
I believe satisfies the OP's needs:
MACRO
LITADCON
DATAAREA LOCTR ,
L DC
LOCTR ,
DCA(L)
MEND
TESTPGM CSECT ,
The simple answer is to access data in other address spaces than the one in
which your code is currently running. There are other more complex reasons as
well, but that's the simplest.
The Principles of Operations manual is quite clear about the use of access
registers. If you start there
<*Chuckle*> I first heard that one as "You can write assembler in any language"!
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Paul Gilmartin
Sent: Thursday, October 12, 2017 9:28 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
You could use character symbol subscripting and extract the numeric part of
_OPTABLE (select everything from position 3 to the length of the symbol)
then assign that character string to a numeric symbol and test that numeric
symbol value.
Of course, if they ever change the "ZS" to something
Thanks for the APAR link. Interesting that there are 151 new mnemonics but only
19 actually new instructions.
Lots of new functions added to existing instructions this time around.
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
It would be really helpful if Appendix A included sample code for those PRNO
programming notes, along with sample code for selecting random integers as
suggested in Appendix A of the NIST document referred to in PoOP note 18 in
section "Other Publications" here:
OT: I would disagree that ICSF is the "overall better choice". IMHO, if you do
not need unique Crypto Express co-processor functions or completely and totally
secure keys then ICSF is just wasted overhead compared to using the native
CPACF instructions.
I have measured the difference between
If your assembler program is LE-enabled, you might consider using the C library
regular expression builtin functions. For each "Acceptable value" structure
you would (one time) construct a regular expression consisting of literals for
fields with values and the regular expression ".+" ("match
Better link to the SHARE session page, from which the PDF may be obtained:
https://share.confex.com/share/119/webprogram/Session11408.html
Thank you Tom Marchant for an excellent and very helpful presentation!
Peter
-Original Message-
From: IBM Mainframe Assembler List
Profound thanks
Peace be w/y'all
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Tuesday, May 16, 2017 4:51 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: random quest
1. Use either CEERAN0 o
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Tuesday, May 16, 2017 5:03 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: random quest
>
> > On 2017-05-16, at
1. Use either CEERAN0 or FUNCTION RANDOM to generate a column of 99,999
random numbers. It's OK if there are duplicates.
2. Add a second column using SORT with sequential numbers from 1 to 9
(use the SEQNUM option).
3. SORT by the first column only and DO NOT specify the
Excellent idea! Could be a superb mechanism for setting up instruction-tracing
or debugging software (see program TRACE390 in CBT file 391, for example)
without the overhead of ESTAE or the (currently unsupported under z/OS) TRAP
exits.
But perhaps not directly from any general register
PMFJI, but really, even for non-LE subroutines how hard is it to save your
registers in your own R13 area, write an inline WTO with message indicating
where and why you want to blow up and an ABEND macro right after? Yes, the WTO
is non-reentrant. Making it reentrant is not that hard. IMHO
Let's think about the old way and the new way:
Old Way:
L Rx,BinaryVariable
CVD Rx,WorkDblWd
UNPKZoned_Decimal_Target,WorkDblWd
* And then fix the sign nibble for unsigned target with (perhaps) OI
target+length-1,X'F0'
New Way:
L
FWIW, I don't know for sure if using the base register as an index register
instead has any CPU penalty, but I got so used to coding it "the right way" so
long ago it's my default behavior. If I'm not actually using an index
register, I always code the comma to indicate it is unused.
Peter
And one could also ask for full support of and regular automatic updates of the
tz database, which AFAIK is not present at all in z/OS Unix.
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Paul Gilmartin
Sent: Wednesday,
@LISTSERV.UGA.EDU
Subject: Re: CONVTOD Help
On 2017-04-11, at 15:48, Farley, Peter x23353 wrote:
> A shorter approach would be to use the actual 1970-01-01 00:00:00 epoch date
> in STCKE format:
>
> X'007D91048BCA'
>
> Subtract that value from the first 64 bits of STCKE and t
A shorter approach would be to use the actual 1970-01-01 00:00:00 epoch date in
STCKE format:
X'007D91048BCA'
Subtract that value from the first 64 bits of STCKE and then divide by
F'160' to get seconds since the Unix epoch.
Of note, a recent Metal C compile of that algorithm with
Subject: Re: How to automatically position generated data areas after all
program-defined areas
On Fri, Mar 17, 2017 at 1:31 PM, John McKown <john.archie.mck...@gmail.com>
wrote:
> On Fri, Mar 17, 2017 at 1:22 PM, Farley, Peter x23353 <
> peter.far...@broadridge.com> wrote
1 - 100 of 214 matches
Mail list logo
