BM Mainframe Assembler List Em nome
>> de Chris Craddock
>> Enviada em: quarta-feira, 9 de agosto de 2023 11:34
>> Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>> Assunto: Re: Automation in C++ vs HLAsm WAS: looking for limbo languages -
>> how low can you go?
>>
>&
And here's the 2nd part of the Jon/Chris magnum-opus...
Jon >> 6. You said "IBM's C++ running APF authorized under LE in a z/OS STC".
My design very rarely runs authorized and could easily
Jon >> be written in any language. In your z/OS STC design, did you run
authorized regularly? Init for
ld be sorely tempted
to reuse this approach. Worked like a charm.
CC
From: IBM Mainframe Assembler List on behalf
of Phil Smith III
Sent: Wednesday, July 19, 2023 4:38 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: looking for limbo languages - how low can you go?
Chris Craddock wrot
Hi Jon,
"It's silly to say that C hardware near. I would say less than 5% of the x86 or
z instructions are used by the language."
I just delivered a brand new z/OS automation product that's about 40% HLASM and
60% C++. Yes really, it's IBM's C++ running APF authorized under LE in a z/OS
STC.
(De-cloaking after years of silence) It's somewhere between lazy and truly
evil.
Lazy because you could just use a label. Why are people so allergic to using
labels ffs?
Evil because it isn't always obvious where you're intending to branch. Perhaps
you calculated the offset wrong. Perhaps
Roughly the same happened to us at the long forgotten BB. We also had a shiny
new P/390 that kept my office stifling hot. I'm guessing it was more like 1995
but it was a long time ago in any case. I would be surprised if it was
available for more than a month or so before it was yanked back.
Date: Wed, 4 Dec 2013 13:37:31 -0600
From: john.archie.mck...@gmail.com
Subject: Re: Base-less programming
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
snip
Am I reading the book right?
No. Although the assembled instructions have the displacement in half
words, your source code should still
I have no dog in this discussion - I am long gone from BMC - but to put this
back on the rails; what Bill Blair was specifically asking for was people who
have deep z/OS development and diagnostic skills.
Dump reading is just one of those skills. In Bill's case they already have
shared product
On Jul 30, 2013, at 7:20 PM, David Cole dbc...@colesoft.com wrote:
Hmmm... I wonder if YREGS came originally from Yale. In the '70s,
Howard Gilbert and I were involved in writing a version of APL that
would run within TSO, and it was sold by IBM as an IUP. (Extra
points if you remember what
(Agreeing with Dave Cole)
Beyond that, the whole idea that you can rationally know the identity of the
calling program is pretty naive. Load modules are composed of multiple
sections, any of which might call any other piece of code anywhere anytime.
Throw multiple modules in being called from
:The next most efficient technique after using a sanctioned slot in the area
referenced by ECVTCTBL is Name/Token services. A System-level Name/Token in
would be needed in this case.
I wonder if IBM has reserved some for the installation.
Nope. It's for vendors - mainly to keep them out
On Jan 1, 2013, at 1:07 PM, Jon Perryman jperr...@pacbell.net wrote:
Below, you say that ALET's for other address spaces is not supported. Does
this
mean if I have ALESERV ADD in a non-pc program that switches to AR mode and
setting the AR to this ALET is not supported? Is it somehow now a
On Dec 31, 2012, at 2:22 PM, Chris Craddock crash...@hotmail.com wrote:
If the User address space space terminates without issuing STORAGE RELEASE,
will the Server Address Space have addressability to the storage area ?
Yes.
Ok I am guilty of being misleading too. If the address space you
Scott ford said
I am in the process of writing a CEEBXITA application specific exit. I
currently have a
LE Cobol 4.2 STC and we process items in storage and/ or could have file
open. What I am trying to do is gain control or intercept the operator
issuing a mvs cancel command against the
SDWA is ALWAYS in the same key as the PSW at entry to the recovery routine.
CC
On Jun 25, 2012, at 5:33 PM, Dave Day david...@consolidated.net wrote:
Jim,
I saw that in the manual. So, if I am running in problem state,
Key 8, can I update the SDWA before executing the SETRP?
Does anyone know if this method eliminates IEF352I ADDRESS SPACE UNAVAILABLE
since master is the owner or will the issuer of ETCON always have this
message?
The issuer of ETCON will always get this message unless ASN reuse is in effect
for the address space.
If you have data areas that should survive beyond the life of the
address space that created them, and you want control over who can work
with those data areas, then there are still some advantages to data
spaces over 64-bit storage.
64-bit shared storage is actually a better fit
Not possible.
Chris Craddock
Sent from my cell phone
281-770-1950
On Mar 4, 2012, at 3:25 PM, esst...@juno.com esst...@juno.com wrote:
Has anyone ever tried to issue a LOAD macro and have the program (i.e Table)
placed directly into a data space.
I have issued MVS LOADS (which is a load
Bill writes:
I try very hard to put a cogent comment on each machine instruction and all
USINGs and DROPs. And I add a paragraph or two at the beginning of small
subroutines. I do this for two reasons: (1) I have spent a lot of time
studying other people's code with either poor or no
Rob said: When I get register poor, I take this a nature's way of telling me
that I need to restructure/redesign the code.
Amen!!
My curiosity is why MVCLE sets the CC, thus forcing user code to branch back.
Why not just not update the PSW instruction address until all the data is
processed? Still allow the interrupt like MVCL does, of course. I understand
why the interrupt is necessary, especially in a single CP
All I want to do at this point is determine where the mismatching BAKR/PR
occurs.
That is quite difficult because from the application point of view, anyone can
issue a BAKR or PR any time and, unless the stack just happens to be full, or
empty relative to the current RB, the instruction will
From a z/OS architectural point of view you're not supposed to be aware of the
linkage stack depth. The (possibly naive) view implicit in the software
architecture is that if your program adds a linkage stack entry then it should
also remove it. Most of the problems you will encounter with the
Date: Thu, 20 Oct 2011 11:10:48 -0700
From: jimphoe...@phoenixsoftware.com
Subject: Conditional assembly test for current AMODE
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Is there a way to test what AMODE is in effect for the current CSECT?
Such a test would be valuable to allow a macro to expand
OK. So, in order to be totally safe when the programmer cannot __guarantee__
that the caller has supplied a proper save area for 64 bit programs (i.e.,
the caller might or might not use the 72 or 144 word save area format), then
one __must__ assume a 72 work standard save area, no? In which
I'm sure that an optimizing compiler can do an amazing job, but in this case
it was Enterprise COBOL vs handcoded Assembler. I have a hard time believing
that COBOL is faster than assembler in any scenario. Enterprise COBOL is our
'main' programming language and I haven't seen it perform
Feb 2011 18:40:57 -0600, Chris Craddock wrote:
given that the service provider has provided a space-switch PC for
the client address space to call, what was the point of the SRB?
There's nothing wrong with it per se, but it just adds more moving
parts which on average is less optimal.
I
Address Space A runs in problem state - key 8.
Address Space A Issues a Program Call instruction which inturn invokes a
Cross Memory Space Switching Routine (in the Vendors Server Space B). The
PC-ss routine executes in supervisor state,
and its only responsibility is to schedule an SRB
I'm wondering if the following is a good idea. I've been reading again. If I
have a routine which does the following:
...
CALL MYSUB,(PARMS,...),VL
L R13,4(,R13)
RETURN (14,12),T,RC=(15)
and I'm using standard calling conventions and save areas, is
One questions how there would be addressability to either the VCON or the
parms.
You're right of course. I wasn't bothering with the details. If it were me and
I wanted to do it this way, I'd get the parmlist address (R1) and branch
address (R15) set up inline and then restore R2-R14 and
wow what a busy topic! At the risk of throwing gasoline on a burning building,
I have to say it sounds like a lot of people are struggling to write baseless
code (or whatever is eventually decreed as the politically correct term) just
for the sake of being baseless. It is obviously very trendy
I am trying to set a SLIP trap for a SRB routine (APXABBVS) that runs in
the JES2 address space. The trap is not intercepting the abend. The
SYSUDUMP shows the S0C4 location after the SCHEDULE macro in the main
program. Any thoughts?
SLIP
My friend Peter Relson writes:
I readily grant that the books are too often wrong. But that does not
lessen their official-ness. Help us to get them right.
I am all in favor of following the documented interfaces where ever possible,
however the books are not just often wrong. They are
Maybe we need the z/OS manuals in a wiki somewhere so that we can all chip
in :-)
Rob Scott
that would certainly help salvage and preserve the community knowledge about
the platform. (IMO) One of the main reasons that people are not building
sophisticated software for the platform is
Has IBM opened up the ZIP and ZAP TCBS to software vendors/developers ?
It was my understanding that IBM did not want to disclose that.
Is there a documented interface ?
Yes there is a documented interface and IBM does disclose it. First, a little
background... zAAP engines are chosen by the
Why does the data for a CDS need to be on a doubleword anyway?
It just does
Or if you want the more gory explanation... it has to do with storage operand
consistency rules. CDS is built on top of the hardware memory architecture and
so it has to play within the same rules as other storage
36 matches
Mail list logo
