On Jan 31, 2022, at 12:31:15, Dave Clark wrote:
>
>I have two pairs of encoded bits in the high order of a binary
> byte. These two pairs (values of 0 to 3, each) actually represent the
> numbers 1 to 4 in each case. Now, I know that I could do this the hard
> (long?) way by
On Jan 26, 2022, at 09:56:18, Peter Relson wrote:
>
> Some more info from the REXX folks:
>
> The savearea passed to programs invoked via ADDRESS LINK, LINKMVS, or
> LINKPGM was extended to pass
> a 144-byte savearea to the caller by APAR OA44581 (whenever that became
> available). ...
>
On Jan 26, 2022, at 10:57:44, Tom Marchant wrote:
>
> ATTACH(X) always passes a 144-byte save area since about z/OS 2.3.
> EXEC PGM= invokes your program with ATTACH.
>
When did the rules change? In days of yore I was led to believe that any
program
that could be invoked with /STEP EXEC
On Jan 26, 2022, at 09:34:49, Joseph Reichman wrote:
>
> The copy book is assembler
> It tells me the name of the variable it’s length
> And it’s offset which would be it’s value
>
> I have one Simple question
>
> This url
>
>
On Jan 26, 2022, at 09:56:18, Peter Relson wrote:
>
> Some more info from the REXX folks:
>
Thanks.
> The savearea passed to programs invoked via ADDRESS LINK, LINKMVS, or
> LINKPGM was extended to pass
> a 144-byte savearea to the caller by APAR OA44581 (whenever that became
> available).
>
On Jan 26, 2022, at 08:09:14, Joe Reichman wrote:
>
> Thanks but that would never here at the IRS this place is highly sensitive to
> anything from the outside
>
It's hard for these fora to help you if:
o You can't show the failing code.
o You can't accept working examples from outside.
On Jan 25, 2022, at 11:03:23, Ed Jaffe wrote:
>>>
>> Fixing it should take precedence over documenting it. Through a half-century
>> IBM has documented too many things that should have been fixed.
>
> Your assertion suggests the existing functionality broken. It's not.
>
> There is nothing
On Jan 25, 2022, at 09:24:10, Peter Relson wrote:
>
> The REXX team indicates that the current savearea size for a called
> routine is 72 bytes.
> This will get documented. Thanks Shmuel for submitting the update request.
>
Fixing it should take precedence over documenting it. Through a
On Jan 3, 2022, at 12:35:15, Joseph Reichman wrote:
>
> Aware of what
> ...
>> On Jan 3, 2022, at 2:30 PM, Seymour J Metz wrote:
>>
>> You have to be aware regardless.
>>
>>
>> From: Joseph Reichman
>> Sent: Monday, January 3, 2022 2:06 PM
>>
On Jan 3, 2022, at 12:06:53, Joseph Reichman wrote:
>
> I’m just trying to generate the 4 fields need
> To define a variable to Rexx when using assembler
> 1) length of fetch value
> 2) address of the name of the variable
> 3) length of variable name
> 4) address of the fetch buffer
>
> On Jan 2, 2022, at 08:48:38, Martin Trübne wrote:
>
>>> Does it grok SYSIN and SYSLIB in z/FS files?
>
>
>>> For the record: My HLASM debugger eats source code to support
>>> source-debugging.
>
> To make this a little clearer: It absorbs source-listings whichever way the
> HLASM produces
On Jan 2, 2022, at 01:15:38, Martin Trübner wrote:
> ...
> For the record: My HLASM debugger eats source code to support
> source-debugging.
>
Does it grok SYSIN and SYSLIB in z/FS files?
-- gil
On Dec 30, 2021, at 16:25:27, Joseph Reichman wrote:
>
> You think processing adata is simpler I mean they data names are not in
> order
>
Oh, they're in order. The order is just undocumented.
>> On Dec 30, 2021, at 5:41 PM, Bob Raicer wrote:
>> ...
>> For reasons lost in antiquity, an
On Dec 29, 2021, at 10:54:06, Joseph Reichman wrote:
>
> The data I am trying to access is variable and complex to get too
>
> Would like to read the asm copybook via assembler AREAD generate and put them
> into variables with Rexx variable having the same name as the assembler
>
Mark Zelden
On Dec 29, 2021, at 07:42:08, Seymour J Metz wrote:
>
> You'd have a similar problem with
>
> FIELDA DS7CL10
>
> The length would be 10, not 70.
>
The OP was envisioning LOCTR. I'd consider ORG:
X1 DS7CL10
X2 EQU *-X1
ORG X1
FIELDA DSCLX2
But it's
> On Dec 20, 2021, at 12:57:41, Alan Atkinson wrote:
>
> Which is just what we did - but turned it onto a macro.
>
> MACRO
> SHI , SUBTRACT HALFWORD IMMEDIATE
> AHI ,-()
> MEXIT
> MEND
>
(Are the parentheses needed around a SETA symbol? I see
On Nov 30, 2021, at 16:12:18, Retired Mainframe wrote:
>
> Look up the DOUBLE character-valued built-in function in your Assembler
> Language Reference. The description specifically mentions this situation.
> It
> is in chapter 9 in my very old reference.
>
E.g.:
On Nov 30, 2021, at 11:51:40, Laddie Hanus wrote:
>
> How about all of that code written before 64 bit z. I had stuff as old as
> 1985 still running in 2017.
>
The interface specifications should require 31-bit linkage conventions.
That should have been explicit ni 1985 to preclude 24-bit.
On Nov 30, 2021, at 11:21:51, Mark Hammack wrote:
>
> If the caller only passes a 72 byte save area (rather than part of a larger
> save area stack) then I've got bigger problems than how to test and/or set
> c'F4SA' in the save area. :-)
>
The code of the subroutine should cut the Gordian
On Nov 30, 2021, at 10:07:51, Gary Weinhold wrote:
>
> Actually the 24-bit architecture wasn't the legacy problem as much as
> not restricting the leading byte of a fullword (whether in memory or
> registers) that the hardware would interpret as an address. That led to
> the use of the
On Nov 30, 2021, at 09:10:03, Martin Ward wrote:
>
> On 30/11/2021 15:53, Mark Hammack wrote:
>> using the high half of R14 may be an option. ...
>
> Does anyone still remember the problems caused by clever
> programmers using the top 8 bits of a 24 bit address to store data
>
Didn't IBM do
On Nov 29, 2021, at 12:41:51, Ngan, Robert (DXC Luxoft) wrote:
>
> DON'T DO THAT!
> I had to find/redo all our code that did this when our subroutine return
> logic was changed to use a BIC instruction.
>
Which of you violated standard linkage conventions?
My understanding is that R14 is
On Nov 27, 2021, at 13:10:21, Mike Hochee wrote:
>
> Like most developers I attempt to keep things in GPRs, both high and low
> halves, as much as reasonably possible to improve performance.
>
I had a co-worker who used part of the Register Save Area as
temporary storage, avoiding
On Nov 25, 2021, at 12:49:20, Steve Smith wrote:
>
> My suggestion of using R14 for the base was because it's already set by the
> call to the subroutine.
>
RR15? (BALR 14,15)
-- gil
> On Nov 23, 2021, at 15:23:49, Charles Mills wrote:
> ...
> LA somereg,=C'blah')
>
> And an EX rather than an L. Would that work for you? Does require a base
> register. LARL would not, but it's 6 bytes rather than 4.
>
Does an EX of an LARL displace relative to the location of the
On Nov 23, 2021, at 15:17:59, Ngan, Robert (DXC Luxoft) wrote:
>
> ... I'd need a second yonder LOCTR to separate the table entries from the
> character strings, since the table entries need to be contiguous.
>
That's the easy way.
> I'll use for the names, cache 'em, and generate them with
On Nov 23, 2021, at 14:14:44, Ngan, Robert (DXC Luxoft) wrote:
>
> That complicates my code, where I wanted to do this to generate table
> entries. Now I need a separate named field for each generated table entry!
>
Would a MACRO using LOCTR and simplify it?
> -Original Message-
>
On Nov 23, 2021, at 12:40:13, Ngan, Robert (DXC Luxoft) wrote:
>
> Why can't I code:
>
> DCA(=C'blah')
>
> This give an ASMA030E error, but wanting the address of a literal string
> seems legitimate to me as I don't otherwise need a named field with this
> value.
>
Jonatnan
On Nov 20, 2021, at 08:45:38, Phil Smith III wrote:
>
> Mario Bezzi wrote about inline assembler being optimized out of existence.
>
> Seems APARable, no?
>
That's perfectly reasonable behavior for peephole optimization
which detects otiose instructions. Why should it preserve
"BCR 0,0"?
On Nov 18, 2021, at 08:20:50, Charles Mills wrote:
>
> I know this is above your pay grade but why not open source it? I'll bet
> there are a half a dozen folks that would love to get it working on current
> Windows and perhaps Linux too.
>
What source language? If ASMPUT originated on OS/2
On Nov 17, 2021, at 02:36:12, Jonathan Scott wrote:
> ...
> When we resumed this item recently, we found that the logic to
> handle the dependent USING base address and range in the Using
> Map and Active Usings headings incorrectly assumed that any
> dependent USING would be basing the start
On Nov 15, 2021, at 08:38:32, Ian Worthington wrote:
>
> I loved bookmaster back in the day (though the script underpinnings, not so
> much), never really found an adequate tool to replace it. Tried lyx for a
> bit and was finally persuaded to use latex, but it's still not as productive
> as
On Nov 14, 2021, at 14:52:12, Charles Mills wrote:
>
> Well, not sure it's sensible but "z Architecture" is not a "feature of z/OS."
>
Yes, but still a hyperlink would be useful.
> Yes, yes, of course, not very sensible. z/OS only runs on one type of
> hardware, and any assembler developer
On Nov 8, 2021, at 16:42:40, Charles Mills wrote:
>
> Are the rules special for literals?
>
> Yes. Literals have always aligned on a "multiple-of-length-power2" boundary.
> =CL8... will be on a doubleword.
>
And LA R1,-CL128'x' on a 128 byte boundary?
>> What if you want a speciic length?:
>>
On Nov 8, 2021, at 13:57:10, Melvyn Maltz wrote:
> ...
> LARL R3,=C'ABCDE-'
>
> Yes, it's a 5-byte literal extended to 6 to keep the LARL happy
>
Does giving a character constant even length guarantee even
alignment? I'm thinking of such as:
DC. 0H'0'
EVEN DC C'?'
ODD DC
On Nov 8, 2021, at 08:13:09, Seymour J Metz wrote:
>
> What's wrong with using LOCTR in a customer-facing macro?
>
It requires an unlikely degree of coordination between
vendor and customer leest a construct like the following
unwittingly occur:
BAR LOCTR
USING *,2
* ... (More stuff)
FOO
On Nov 8, 2021, at 06:35:20, Martin Truebner wrote:
>
>
>>> I'm curious how you EQU to generate an S-constant properly.
>
> Like this:
>
> * below are for USE by EX against instructions in Literal pool
>SETC 'X''512''(13)'
>SETC 'X''512''(5)'
>
ITYM:
SETC
On Nov 8, 2021, at 01:26:34, Martin Truebner wrote:
>...
> I never had readability concerns/complains about this
>
> EX R4,=S(,TARGET,SOURCE)
>
> with appropriate EQUs at the beginning of the code.
>
I'm curious how you EQU to generate an S-constant properly.
> Well; almost never.
On Sep 6, 2021, at 09:16:46, Seymour J Metz wrote:
>
> That's an issue of nomenclature, not functionality. ...
>
And that nomenclature may vary among the various supported
OSes: z/OS, z/VSE, Linux for z, z/TPF, (others?)
> There is no way that the assembler can test for either reentrancy or
>
On Sep 5, 2021, at 16:36:24, Seymour J Metz wrote:
>
> There are limits to what the assembler can correctly identify. IMHO, while
> there are both false positives and false negatives, the current test for R/O
> code is useful.
>
But given that a RENT object is allowed to modify itself (with
(Cross-posting to IBM-MAIN and ASSEMBLER-LIST)
It's a shame that HLASM (AFAIK) conflates IBM's venerable use of
RENT and REFR.
This has led to misunderstanding in this long IBM-MAIN thread.
And recurrent false reporting by HLASM of RENT violations in
code that is RENT-compliant but merely
(Cross-posting to ASSEMBLER-LIST, but not Linux)
On Aug 1, 2021, at 8:33 AM, Dave Jones wrote:
>
> How can I order the HLASM for Linux on Z? I can't find any information
> anywhere about how to do that.
>
I’ve seen it discussed here; it must exist’. I don’t know where.
I understand it
On 2021-06-19, at 09:23:45, FancyDancer wrote:
>
> If you don't have access to IBM's HLASM ToolKit Structured Programming
> Macros, or if you have the requirement for more complex logic with an IF
> macro, then this small, FREE package might well be the answer. Its IF macro
> is easy to learn
On 2021-05-03, at 10:59:50, FancyDancer wrote:
>
> If you have a record that contains data that you ALWAYS want to assign to a
> set symbol, why not just use the data that you want in a SETC operation?
>
I don't know what Tony was trying to do, but I suspect he was thwarted
by a lack of
On 2021-05-03, at 12:14:07, Ngan, Robert wrote:
>
> Or: DC 0F
>
No. Read what Charles wrote and envision an operation exception.
> -Original Message-----
> From: Paul Gilmartin
> Sent: Friday, April 30, 2021 19:48
>
> On 2021-04-30, at 16:17:06, Charles Mills wr
On 2021-04-30, at 16:17:06, Charles Mills wrote:
> ...
> And #3 the
> DS 0F has a 50-50 (or 3 in 4, depending on how you look at it) chance of
> generating a couple of garbage-filled slack bytes.
>
That's what CNOP is for.
-- gil
On 2021-03-10, at 22:10:14, robi...@dodo.com.au wrote:
> ...
>>
>> You can use LA to subtract 1 if you have a negative value
>> in a base register, subject to the same limit.
>
> Why would you do that, when BCTR R,0 will do it for free
> with even zero as the source register (you get true -1
> On 2021-03-10, at 18:21:11, Robin Vowels wrote:
>
> From: "Schmitt, Michael"
> Sent: Thursday, March 11, 2021 10:26 AM
>
>
>> 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?
>
>
> On 2021-02-15, at 09:12:38, Jonathan Scott wrote:
>
> Ref: Your note of Mon, 15 Feb 2021 09:39:42 -0600
>
> John K wrote:
>> Is it possible to generate AMODE, RMODE, and RSECT statements on a
>> disassembly?
>
> Not at present, sorry.
>
> AMODE and RMODE are on a long list of potential
On 2021-01-30, at 12:23:03, Charles Mills wrote:
>
> Not an MVS- or IBM-specific comment at all ...
>
> Hardware documentation tends IMHO to be rigorous. The PoOp -- just as an
> example -- tells you exactly what will happen for many "stupid -- don't do
> that" cases, such as branching to an odd
On 2021-01-29, at 06:25:28, Peter Relson wrote:
>
> As Keven Hall mentioned, If it were required that there be no crossing of
> page boundary from TBEGINC through TEND, the principles of operation would
> have said so.
>
> There is no such requirement.
>
It appears that the editorial rules
ather than "is"?
> On 2021-01-21 9:35 p.m., Paul Gilmartin wrote:
>> On 2021-01-21, at 19:07:36, Gary Weinhold wrote:
>>> ... the GET still has a "L 15,24(1)".
-- gil
On 2021-01-21, at 19:07:36, Gary Weinhold wrote:
>
> ... the GET still has a "L 15,24(1)".
>
Is there any harm in that? In days of yore there may have
been a performance penalty, but now?
In a contrived case, it may depend on displacement reach:
USING 5000,2
LA
On 2021-01-19, at 07:47:39, Peter Relson wrote:
>
> Gary W wrote:
>> I recall we had to do it to produce reentrant code with some IBM macros
> about 20 years ago.
>
> ...
> Please consider helping yourself and others by opening an RFE. I think the
> team might consider making such updates,
On 2021-01-15, at 09:36:17, Mark Henderson wrote:
>
> Is anyone aware of something (official hopefully) in the assembler, MVS or
> TCP/IP that gets around the requirement for a base register when using the
> EZASMI macro ? As things stand the macro generates inline constants that are
>
On 2021-01-03, at 16:39:38, Gibney, Dave wrote:
>
> In the general case (amiglib perhaps an exception) to expect a DLIB
> (HLQ.Axx) to provide valid executables.
>
Not in thee general case. A DLIB may contain objects which need
to be linked with library subroutines to be valid
On 2021-01-01, at 08:22:04, Seymour J Metz wrote:
>
> I hope that there is at last a warning associated with that, if not an option
> for strict enforcement: the most recently active CSECT might not be what was
> intended.
>
>
> From: Jonathan Scott
>
On 2020-11-19, at 19:12:21, Don Higgins wrote:
>
> I don't think there is any charge to get an IBM ID. Just register with name
> and email. I've had an ID for many many years.
>
True. I just logged in with my IBM ID which is an email address
which has been invalid since 2004.
However I
> On 2020-11-17, at 10:21:10, Binyamin Dissen wrote:
>
> On Tue, 17 Nov 2020 13:58:23 + Seymour J Metz wrote:
>
> :>Indeed, OS/360 had some code that was reentrant but not refreshable; AFAIK
> IBM has cleaned up all such abominations, and the binder does not allow you
> to create a load
On 2020-11-16, at 17:47:10, Dan Greiner wrote:
> ...
> So, the facility only applies to virtual addresses on newer models. As I
> recall, the development of this facility was requested by z/Linux in order to
> help avoid classic stack-overflow exposures; but, it obviously has
>
On 2020-11-11, at 14:17:42, Dan Greiner wrote:
>
> I was just informed that the document "The Enhanced-Sort Facility for
> z/Architecture" (SA22-1082-00) is available for download. See
>
On 2020-10-24, at 19:39:43, Tony Thigpen wrote:
>
> I have a lot of xedit macros, including some post edit reformatters, but I
> never thought of that one. But, I don't think I will spend the time on it
> since I rather just switch to mixed case for the few times I really, really
> need it.
>
On 2020-10-24, at 18:35:32, Seymour J Metz wrote:
>
> It is possible to write XEDIT macros to support mixed case comments with
> upper case labels and opcodes.
>
Hmmm... I could imagine:
Treat any token starting in Col. 1 as CASE UPPER.
Treat the first token following a blank on a
On 2020-10-24, at 15:06:32, Tony Thigpen wrote:
>
> ... (I normally use "case mixed ignore" in XEDIT.)
On 2020-10-24, at 16:05:59, Tony Thigpen wrote:
>
> It is a personal preference of mine to never edit an assembler source with
> lower-case turned on. I just do not like mixed case
On 2020-10-24, at 15:06:32, Tony Thigpen wrote:
>
> I kinda like the concept, but a lot of literals we use are just 4 characters,
> so it does not scale down easily.
>
??? "scale"?
> One of the other thoughts mentioned was lower-case vs. upper-case. Maybe a
> macro that accepts upper-case,
On 2020-10-24, at 13:48:42, Charles Mills wrote:
>
> There's another macro exercise. Given MYBLKHDR,'EYECATCH' to generate MVI
> MYBLKHDR,C'E'/MVC MYBLKHDR+1(L'MYBLKHDR-1),=C'YECATCH'
>
> An immediate instructions also "solves" my eyecatcher compare query,
> lamenting the lack of "CLCIN."
>
On 2020-10-23, at 16:32:30, Charles Mills wrote:
>
> Can you code an address expression with a literal? Is MVCIN TARGET,='Foo'+2
> (or 2+='Foo', or some equivalent) valid? If so, you could embed your logic in
> an executable SETEYE macro that would take SETEYE TARGET,'EYECATCH' and
> generate
On 2020-10-22, at 02:02:56, Robin Vowels wrote:
>
> You need to test R15 being zero. Subtracting 1 and then doing an EX
> is potentially dangerous.
>
I wonder whether avoiding this hazard was motivation for
CMS MDFS and SFS and early MVS RECFM=V prohibiting empty
records.
-- gil
On 2020-10-21, at 09:20:31, Seymour J Metz wrote:
>
> Unless performance is an issue, I generally opt for simplicity. If
> performance is an issue I encapsulate it in a macro that generates different
> code for different processors.
>
It's harder for an EQUated symbolic length; worse yet for
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
On 2020-09-10, at 18:14:16, Charles Mills wrote:
>
> Sometimes one uses the same COPY member or macro in a CSECT in one place and
> a DSECT everywhere else. Yeah, you can use SET symbols make it vary between
> the two environments but that is a tad ugly.
>
That's needed only if the CSECT and
On 2020-09-09, at 10:14:05, Bob Raicer wrote:
>
> 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 2020-09-06, at 17:48:18, Charles Mills wrote:
>
>> C also makes a similar assumption, namely that an address
>> greater than that of any object can be used as a list
>> terminator.
>
> I'm not familiar with that convention. How would a C program determine that
> a particular pointer was
On 2020-09-05, at 09:31:51, Ed Jaffe wrote:
>
> On 9/4/2020 10:46 AM, Seymour J Metz wrote:
>> VM uses a token of 8X'FF' at the end of the (R1) parameter list. I don't
>> recall what the convention is for the (R0) extended parameter list
>> introduced by VM/SP.
>
> We've adopted "eight bytes
On 2020-09-04, at 07:39:33, Gary Weinhold wrote:
>
> Nulls
>
There's the conundrum of representing zero arguments in a
variable-length parameter list: theres no last argument on
which to set the VL bit.
> What does JCL generate for an EXEC with no PARM?
-- gil
On 2020-09-04, at 07:23:49, Gary Weinhold wrote:
>
> Even if they'd had the foresight to use a different way to indicate the
> end of a parameter list, I don't think they were consciously seeing not
> changing the extenal architecture of the hardware for 40 years.
>
Terminatingthe argument list
On 2020-09-02, at 14:40:59, FancyDancer wrote:
>
> I really enjoyed "meeting" all of you at today's session. I mentioned that I
> have rented time on a zOS system to test some macro code using HLASM. The
> following is the reply that I received back from my first inquiry into
> getting access
On 2020-08-11, at 09:11:28, Jonathan Bradbury wrote:
>
> I forgot to add that these instruction never actually get executed, no
> exclusive-OR or subtraction is done. Instead the instruction decoder
> recognizes these cases and during register renaming which is part of
> out-of-order
On 2020-08-10, at 15:38:14, Gary Weinhold wrote:
>
> i use digests for high-traffic listservs, but not assembler list.
>
For an experiment I wanted a small digest. It appears that
ASSEMBLER-LIST publishes digests daily at 00:00.
> Thunderbird on PC seems to know to reply to the list and but
On 2020-08-10, at 16:28:28, Steve Smith wrote:
>
> 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.
>
However, the newer z models have a whole family of new
instructions which
As an experiment I set my subscription to ASSMBLER-LIST to
DIGEST for one day. MacOS Mail.app shows the digest as
a single stream of messages with unrendered Quoted-printable.
There seems to be no way to reply to a single message, only
to the entire digest.
Thunderbird does somewhat better I can
On 2020-08-08, at 15:19:05, Charles Mills wrote:
>
> Or a dozen or more other non-magic ways of getting into supervisor state.
>
How does this interact with IBM's Statement of Integrity:
https://www.vm.ibm.com/devpages/SPERA/istatmnt.html
...
IBM will accept all APARs that describe
On 2020-08-08, at 11:20:25, Robert Netzlof wrote:
>
> But do remember that in Ye Gude Auld Days, there was a widely known
> "magic" SVC which granted authorization to the user.
>
"Widely known"? But wasn't it always site-specific, never
distributed by IBM in a base system? Likewise
On 2020-07-09, at 18:19:36, Swarbrick, Frank wrote:
> ...
> 4) When you edit "host side" files, are you editing and saving directly to
> the host each time you save, or are you editing locally and then have a
> separate step to save to the host? In either case, what is the "method" used
>
On 2020-07-05, at 17:45:11, Peter Relson wrote:
>
> There ought to be a warning on any such truncation
> although it probably couldn't be detected until the
> point of LOAD/LINK/ATTCH.
>
>
> There is information provided about such truncation. It is done at bind
> time according to the RMODE.
On 2020-07-04, at 23:08:31, Keven wrote:
>
> 2-byte RLD entries are correctly handed by the link-editor/binder and
> as far as I know they aren’t deprecated. Why would their use by Pl/I (to use
> your example) perturb you?
>
My understanding is that Q-constants are offsets into an
On 2020-07-04, at 07:23:39, Peter Relson wrote:
> ...
> z/OS has never, to my knowledge, supported 1-byte relocatable adcons. And
> of course use of a length-2 RLD is kind of questionable (unless a
> truncated value is what you are going after).
>
There ought to be a warning on any such
> On 2020-07-02, at 17:44:38, Dan Greiner wrote:
>
> The following simple program illustrates address constants of various sizes:
>
> RLDNFG CSECT
> ADCAL1(H)
> BDCAL2(G)
> CDCAL3(F)
> DDCAL4(E)
> EDCAL5(D)
> FDCAL6(C)
> G
On 2020-06-09, at 14:46:30, Seymour J Metz wrote:
>
> No Rexx implementation; it's the original PL/I syntax.
>
>
> -Original Message-
> From: Seymour J Metz
> Sent: Tuesday, June 9, 2020 1:54 PM
>
> If and when ANSI updates the Rexx standard, I
On 2020-06-09, at 13:44:57, Bob Raicer wrote:
>
> I am certainly not a fan of using the Condition Code as a return
> value from a called function. It is rather limited (only a two bit
> integer) and does not work for functions invoked by other
> programming languages (for example, "C").
>
I
On 2020-06-08, at 18:08:42, Seymour J Metz wrote:
>
> Off the top of my head
>
Excellent for top of head:
821 $ diff -su trotorig trot
--- trotorig2020-06-08 18:44:19.0 -0600
+++ trot2020-06-08 20:02:31.0 -0600
@@ -6,8 +6,8 @@
LCLC ,
DS0CL256
I
get (*-TABLE) in conditional assembler?
> ____
> From: Paul Gilmartin
> Sent: Monday, June 8, 2020 1:20 PM
>>
> TROT is way easy in Rexx:
>
> signal on novalue
> do Line = 0 to 15
> Chars = " DCC'"
>do Col =
On 2020-06-08, at 00:33:08, Pieter Wiid wrote:
>
> I did create a macro to build the table -- and one for TRTO, to convert
> display to hex.
>
TROT is way easy in Rexx:
signal on novalue
do Line = 0 to 15
Chars = " DCC'"
do Col = Line * 16 to Line * 16 + 15
Chars =
On 2020-06-02, at 19:37:25, Gary Weinhold wrote:
>
> I recall that VM/370 CP routines set CC before returning to the caller;
> I don't have access to the source anymore (for the last 30 years or so)
> to verify this and what technique was used. I just remember thinking it
> was different and
On 2020-06-02, at 15:53:34, Keven wrote:
>
> Are you suggesting the use SPM/IPM as an alternative to setting the
> actual condition code?
> K3n
>
I opposed it; its proponent outranked me.
> On Tue, Jun 2, 2020 at 4:45 PM -0500, "Paul Gilmartin"
>
&g
On 2020-06-02, at 15:30:33, Dan Greiner wrote:
>
> Using the indexed branch allows for many more possible actions -- not just
> binary true/false -- but may necessitate accommodating all possible branch
> cases following each return. I also agree that the indexed branch approach
> may be more
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
On 2020-06-02, at 11:30:20, Schmitt, Michael wrote:
>
> I wrote an entire AVL tree based caching program using the HLASM Toolkit
> Feature Structured Programming macros, but then had to rewrite to remove the
> macros when the company decided to no longer pay for the feature.
>
> Now IBM is
On 2020-06-02, at 11:30:20, Schmitt, Michael wrote:
>
> I wrote an entire AVL tree based caching program using the HLASM Toolkit
> Feature Structured Programming macros, but then had to rewrite to remove the
> macros when the company decided to no longer pay for the feature.
>
I believe
On 2020-06-02, at 11:21:23, Seymour J Metz wrote:
>
> SIGNAL in PL/I is well behaved; in REXX, not so much.
>
> I like REXX, but it would have been much cleaner had iterate and leave used a
> label on the do rather than using the control variable.
>
Yes.
> It would also have been cleaner had
201 - 300 of 1103 matches
Mail list logo
