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
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
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
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
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
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
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
>
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
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
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
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
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
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
> 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
>
>
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
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
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
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
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:
> >
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
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
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.
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).
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
"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:
>
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
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
>
>
>
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
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
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
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
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
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
ork).
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)
> ???
>
>
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
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
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 respon
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
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,
--->
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 a
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,
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
>
>
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
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
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
FWIW, I think both the Principles of Operation and the HLASM Reference are
the epitome of manuals.
sas
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
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
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
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
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
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
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,
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
. 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)
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
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,
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
...some BASR R14, or JAS R14, etc.
USING *,R14
B *+4(R15)
DROP R14
JRC0ROUTINE
JRC4ROUTINE
JRC8ROUTINE
sas
That's great! Explaining things like "ST USING
STATUS_TABLE+4000,STATUS_DESC+4000 " makes people suspect me of witchcraft.
sas
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
>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
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
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
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
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 |
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
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
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
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?
>
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
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
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
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 <
STSERV.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
>
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
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
re 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
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.
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
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
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
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
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
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
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
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 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
>
I wish IBM would add the LZR instruction just so this question could stop
being asked.
sas
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
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
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
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
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
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
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
>
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
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:
> ...
>
>
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
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
1 - 100 of 294 matches
Mail list logo
