The short answer to your question is No.
I think you have a fundamental misunderstanding of the operation of
the Linkage Stack mechanism.
You should carefully read "Chapter 2. Linkage stack" within IBM
publication SA23-1394-00 "z/OS MVS Programming: Extended
Addressability Guide" (this is the z
How about posting a hex dump of your complete DYNALLOC interface
data structures upon return from your Unallocation request:
S99RB: the DYNALLOC Request Block
S99RBX: the DYNALLOC Request Block Extension
S99TUNIT: the complete set of DYNALLOC Text Units
IGDMCSMG: the set of SMS/DYNALLOC
The scenario you describe creates, at the minimum, race conditions
and you can (and likely will) get a S301 ABEND. (Attempting to
WAIT on an ECB which already has its WAIT bit set to one).
Speaking as someone who has worked on OS and I/O subsystem
development for more than 45 years, I wholeheartedly agree with the
comments and observations posted by Brent Longborough. I've always
found the style of invoking some function and depending upon the
Condition Code upon return to be worse
Well, the statement from Peter Relson (and others) which is
essentially:
--
LA R1,1 is exactly equivalent to LA R1,1(0). Just look at the
generated object code.
--
is not totally true. It all depends upon which USINGs are in effect.
Take a peek at the following example (admitted
d that block, and any active block inside it, are then
ended. Control then passes to the clause following the END that
matches the instruction of the selected block."
The ANSI Standard for Rexx (X3J18) has not been updated since
1998 and consequently does not reflect the notion of the "Label"
keyword on "Do", etc.
Bob Raicer
0001 0016 A 2 +
0001 0001 0000001C A 3 +
0001 0001 0023 A 4 +
Bob Raicer
On Sun, 6 Sep 2020 16:48:18 -0700 Charles Mills wrote:
> I'm familiar with the use of NULL as a "special" value. I think
> the C standard says that 0 may never be a valid address.
The ISO/IEC 9899:20xx "C" standard cites no restriction on the
value zero being an invalid address.
An extraction f
On Wed, 9 Sep 2020 13:17:24 -0700 Charles Mills wrote:
> Doesn't that say "0 is never a valid address"? Or at least "zero
> never compares equal to the address of any actual object"? "0 is
> never equal to any valid address"? Seems about the same to me.
No, it doesn't say "0 is never a valid a
On Tue, 20 Oct 2020 16:58:52 -0400 Steve Smith
said:
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 wa
Also, long ago and far away, I wrote a Rexx program to read the
assembler source file, perform selective upper casing and write a
new file. Comments (both free standing and line end) were left as
is; labels, operation codes and most operands were upper cased. My
Rexx code did its best to parse th
n some folks use the
"list digest".
Bob Raicer
I've been using (for a shockingly large number of years!) the
approach that Keith Moe and Charles Mills described. It has worked
very well and caused no trouble for my product development and
support teams. All of the products on which I've been a designer
and developer have been nearly 100 perc
Resourcelink user ID and the pub seems to be in a machine
model specific library (for example, the "z15 Model T01 library").
Is there some (sensible) reason for this?
Thanks.
Bob Raicer
I somewhat agree that z/Architecture is not "a feature of z/OS",
however, access to Principles of Operation is mandatory in order to
to write (or even study) assembler code. Numerous other z/OS pubs
make many references to Principles of Operation. For example, the
statements shown below extracte
Using XCF Note Pad might very well be a good choice. I *think* the
service was introduced in z/OS 1.13, and enhanced in z/OS 2.2
Here are some links to a SHARE presentation from 2013 which
describes the facility a bit and offers an example of how SAP has
exploited it.
https://share.confex.com/s
Very Cool, Dan! Thanks for putting together an excellent and
very interest provoking presentation!
Bob
I'm not clear on what you (Joseph Reichman) are attempting to
accomplish. If you are going to produce a Rexx program that does
something with symbols which appear in some form of an assembler
data structure, then you could do something like the example shown
below and (as others have suggested) s
Here is another possibility that uses instructions which have been
available since the publication of the original z/Architecture
Principles of Operation in December 2000. It is only one
instruction longer (and four instruction bytes longer) than the
scheme offered by Dan Greiner, although not as
OK. Let's go through the code one instruction at a time.
I1 LLGC R0,BYTE Low order byte of R0
* contains byte of interest.
*
* Bits 56-59 contain the two
* ad
Making Peter's approach even more old school, use R14 and R15
instead of R0 and R1, and do the character conversion stuff
with Load Address instead of Add Halfword Immediate.
ICM R14,B'1000',BYTE Put the byte into bits 0-7
SRDL R14,30 Move BYTE.0-1 to reg 14.30-
Just for fun, here is yet one more variation on Peter's scheme, using
only S/360 instructions. In the comments, YY and ZZ represent the two
bit pairs of interest, lower case x represents bits or bytes of unknown
value. Bit strings are enclosed in square brackets. Bytes are separated
by undersco
The notion of whether some of these linkage instructions could be
thought of as "save" and "then branch" is interesting and hasn't
changed since the introduction of the S/360.
The fundamental concept is that as a part of normal instruction
sequencing, the addressing information found in the PSW i
Here is another table based scheme which combines sign validation,
sign classification (i.e., the sign is negative or positive) and
recognition of the preferred sign values.
LLC R14,BYTE Fetch the rightmost byte
* of the Zoned Dec
Dave --
I'm not clear on what you mean by "precision" and "scale" when you
say:
"transform a zoned-decimal number with up to 31 digits of precision
and up to 15 digits for scale with an external sign and an explicit
decimal point into a packed number that is properly aligned."
Do you mean "prec
. Which is he using? Do they differ? Is GAAP a requirement? Does
. either Rexx support GAAP? Does COBOL? Does DFP?
Let me start off by stating:
- I don't know what "GAAP" means.
- I am fully aware that Dave Clark is implementing code for z/VSE.
I didn't have any of the IBM z/VSE publicati
. Just to be clear, the original implementation of ReXX was for VM
. in about 1980, well before OS/2.
Oh yes, I totally agree. What I was attempting to say was that the
original implementation published by RexxLA was based upon the
implementation I cited in the IBM announcement letter.
I stil
Thank you, Dave, for your explanation of your use of Rexx stem
variables, and your definition of terms.
Bob
I have used similar logic to "round up" a length or address value
with the same architecturally integral constraints. In this old
code fragment GPR 15 contains the initial value to be adjusted.
Yes, the code needs to be tweaked for 64-bit values.
I guess if I hurt my head a bit I could use the R
Hi Dan. I believe you have run into a couple of glitches in the
z390 assembler.
There is another issue with your WIF macro. The line:
&LABEL LAY &S,-1(&A,&P)
references variable symbol "&A" which is not defined.
The HLASM Language Reference states:
: Use the MEND statement to indicate th
You might want to consider using this (or a similar) code sequence.
It eliminates the use of EXECUTE instructions and verifies that the
length of the source data is acceptable, i.e., the length is
positive and does not exceed the length of the "work area" (field
PWORK16). And, of course, it valid
I'd like to attempt to clear up some common misconceptions about
the Relative Addressing instructions.
The "relative immediate" operand of the relative addressing
instructions is a signed value representing a number of halfwords.
The immediate operand value is effectively doubled and algebraicall
A former colleague sent me this Youtube video link about the IBM
Z16. If you haven't seen the video I think you're in for a treat --
it is pretty cool and funny too.
https://www.youtube.com/watch?v=ZDtaanCENbc
Bob
A couple of more general instructions which require quadword aligned
storage operands and 128-bit values in even-odd pairs of 64-bit
GPRs:
Compare Double and Swap (CDSG)
Compare and Swap and Store (CSST)
Having the ability to assemble quadword aligned 128-bit items for
use with these instruction
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
- begin snippet (from Steve Smith)
That's the old-fashioned way. This is the new way:
ORG *,16
- end snippet
The assembler still cares about SECTALGN. The "old fashioned way"
works fine, independent of SECTALGN. Also, note that I explicitly
stated mapping quad word a
The behavior of LCR, LNR and LPR have not changed since the
introduction of the S/360. Here are some quotes from GA22-6821 "IBM
System/360 Principles of Operation:"
For LCR:
"An overflow condition occurs when the maximum negative number is
complemented; the number remains unchanged."
For LNR:
"
There has been a lot of discussion about the representation of
signed binary integers and the common operations of signed addition
and subtraction on these items.
Since the introduction of the S/360 and continuing on through all of
its largely compatible successors, the representation of signed
b
- begin snippet (from Dave Clark)
That's all well and good, but not germain to the issues being
discussed in this thread.
- end snippet
No worries, Dave. My post was not intended to be a direct response
to you.
I'm also guessing you meant to use the word "germane" (but that's
- begin snippet (from Paul Gilmartin)
I believe what it intends to say is that the two's complement of
the maximum negative number is not its algebraic negation.
- end snippet
I agree with you, Paul, about the "algebraic negation" part of your
reply. However, as perceived by th
While browsing the SA22-7832-13 version of Principles of Operation I
saw this text on Page 1-28:
|Storage-Key-Removal Facility
|
|The storage-key-removal facility may be available on a model
|implementing z/Architecture. A configuration with the
|storage-key-removal facility installed does not h
More than a decade ago when I was working as a developer on the
implementation and support of Extended Address Volumes, the plan
of record was to "functionally stabilize" BDAM. At that time there
was zero work planned or being done on BDAM for EAV support. To be
honest, I haven't paid any attent
I agree with Paul regarding the absurdity he mentioned.
Here's another scheme you might want to consider.
Let's call the set of logical records currently at the beginning of
the data set the Restricted Access Set. Presumably, the remaining
records comprise the Unrestricted Access Set.
You coul
A PDSE is essentially a form of VSAM Linear, where the physical data
set is a collection of 4K-byte blocks. It does not have the notion
of CA's and CI's like other VSAM data sets. The notion of BLKSIZE
is synthesized and mapped onto the internal PDSE structures; the
BLKSIZE value is not the phys
There have been a few posts in this thread that more or less stated
that only complete physical blocks could be read into storage from a
device.
This is not strictly true.
There is the obvious case of truncation, where the number of bytes
the device has been requested to transfer is less than th
First, the mandatory disclaimer: The content of this message is my
personal view only and does not in any way reflect the opinion or position
of my employer.
I couldn't agree more with the overall sentiment about Infocenter -- it's
miserable.
As a developer, I find it very challenging to get th
If what you're really trying to do is to copy the low order 32 bits of
GPR 13 into the high order 32 bits of GPR 0, while leaving the low order
32 bits of GPR 0 unchanged, then the following I-stream will do the job.
RLLG R0,R0,32(0) Exchange the high order and
*
It seems to me that the real problem is that the assembler is
inconsistent with respect to the evaluation of expressions and using
the result of such an evaluation in various contexts.
The HLASM Language Reference clearly states the requirement of
Immediate Data operands for machine instructions:
Here is an example of what I was trying to describe:
ABLE CSECT ,
EXTRN IEFBR14
USING ABLE,R7
LARL R15,IEFBR14
BRC 0,IEFBR14
LHI R15,(IEFBR14-ABLE)
LHI R15,(SECOND-FIRST)
OFFSET DCA(IEFBR14-ABLE)
FIRSTDCF'1'
SECOND
IBM is thrashing about, trying to find ways to reduce the erosion
of profit margins.
Producing high quality product documentation is time consuming and
necessarily involves the resources of many people. Internally,
this is regarded as essentially pure overhead. When this is
coupled with the bel
I'm not really sure what the original question was all about:
===
On Wed, Mar 19, 2014 at 9:04 AM, John Walker wrote:
Rexx execs are EASY. But, Rexx interface, is that something different?
===
Take a look at the EXECIO topic within "Chapter 10. TSO/E REXX
commands" in IBM pub "z/OS TSO/E REXX Reference Version 2 Release 1"
(SA32-0972-00).
Among other things you'll see that specifying "*" as the first EXECIO
operand (this is the "lines" parameter) when DISKW is specified as the
second
John (Walker);
I believe you are confusing the notion of a null terminated string and
a "line" whose length is zero. A "null" character (in both ASCII and
EBCDIC) is a byte whose value is 0x00, i.e., all bits are zero.
In the "C" programming language (and many other programming
languages), the
On Fri, 6 Jun 2014 10:43:57 -0600, Paul Gilmartin
wrote:
> I suspect the restriction (we have it at 1.13) spans many
> releases. How silly to go to trouble to avoid doing nothing.
>
> DISP={OLD|NEW} seems to make no difference. I suspect that DISP
> is among many DD options that are simply ign
DUMMY allocation).
Bob
On 2014-06-07 9:30 AM, Robert A. Rosenberg wrote:
At 08:30 -0600 on 06/07/2014, Bob Raicer wrote about Re: ADRDSSU VTOC -- also
IEBCOPY:
I certainly cannot look at the source code for IEBCOPY, but I
suspect that IEBCOPY simply checks the device type associated with
the
I've noticed that the IBM CELQPRLG macro emits the following
statements unconditionally (the numbers in parens at the start of
each line below are for reference; they are not an actual portion
of the emitted statement).
(1) ENTRY &CEEEPNM
(2) &CEEEPNM DS 0H
(3) &CEEEPNM AMODE 64
(4) &CEEEPNM RMOD
Are you intending to perform the entire document creation process on
z/OS, editing the content by perhaps using some GUI based product,
or perhaps using some form of a "batch" type of a product that uses
markup tags (something similar to the old IBM BookManager product)?
Whatever the tool, if that
I do not believe the suggestion about putting the COPY statement
within a macro definition will work as desired. Here is an
extraction of the description of the COPY statement as it relates to
macros (Chapter 7. How to specify macro definitions, page 227 of
SC26-4940-09 High Level Assembler for z
What David Cole said is sad and true.
After the dissolution of marriage and Kay Bond taking over
the business, David and Kay asked me if I would be interested
in helping Kay with technical support and maintenance of the
Tachyon software suite. I said Yes, and, for a brief time, I
did what I coul
place the content of the
ilrjava directory as found on the z/OS V1R8 "Tools" CD (from the IBM
SK3T-4269-17 Collection) on a site such as Dropbox for you; let me
know.
Bob Raicer
On 2024-03-26 2:35 AM, Jonathan Scott wrote:
where can I find the assembler macros manuals from the old z
Yes, that is the variant which is Java based and which is available
at the URL I included in my post. That variant was constructed as a
native 32-bit Microsoft Windows application which does not require
any additional JRE components. Here is a snippet of prose from the
related "install.txt" file
61 matches
Mail list logo
