Base-less programming

[Tony Thigpen]

I am doing my first attempt at modifying an internal macro to be
baseless. The first two examples are:

NILF R1,X'00FF0000'
LTR R1,R1
BNZ *+4+4
OI 68(R13),X'80'
....

TM 68(R13),X'80'
BNO *+4+6+2
IILF R1,X'FF0000FF'
SVC 12
....

It looks like the first should be changed to
JNE *+2+2
and the second to
JNO *+2+3+1

Am I reading the book right?

--
Tony Thigpen

[John Ehrman]

The distances from instruction to instruction are unchanged; HLASM will
divide by 2 when calculating the halfword offsets. So, 4+4 rather than 2
+2, etc.

John Ehrman

[John McKown]

No. Although the assembled instructions have the displacement in half
words, your source code should still use the original "offset". HLASM
itself will halve the value. And it will complain bitterly if the offset is
not even. So you just replace the B??? with J??? and leave the operand
itself alone.


>
> --
> Tony Thigpen
>



--
This is clearly another case of too many mad scientists, and not enough
hunchbacks.

Maranatha! <><
John McKown

[Kirk Talman]

yes but JNZ is also valid




Mnemonic using
base register
relative addressing

base register
relative addressing
B
J
NOP
JNOP
BAS
BRAS
JAS
BCT
BRCT
JCT
BXH
BRXH
JXH
BXLE
BRXLE
JXLE
BE
BRE
JE
BNE
BRNE
JNE
BH
BRH
JH
BNH
BRNH
JNH
BL
BRL
JL
BNL
BRNL
JNL
BP
BRP
JP
BNP
BRNP
JNP
BM
BRM
JM
BNM
BRNM
JNM
BO
BRO
JO
BNO
BRNO
JNO
BZ
BRZ
JZ
BNZ
BRNZ
JNZ



IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
12/04/2013 02:29:33 PM:

-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you

[Chris Craddock]

> Date: Wed, 4 Dec 2013 13:37:31 -0600
> From: john.arch...@gmail.com
> Subject: Re: Base-less programming
> To: ASSEMBL...@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 use the original "offset". HLASM
> itself will halve the value. And it will complain bitterly if the offset is
> not even. So you just replace the B??? with J??? and leave the operand
> itself alone.

Well.. yes, but being pedantic; how about just using a label?!? I cringe whenever I see carefully crafted branch statements with instruction lengths. That's trivially broken by any down-stream change, whereas a label as a jump or branch target will never be wrong - no matter how much the code changes in between. Make your own and the next poor fool's job easier.
Just saying....
CC

[John McKown]

Well, I don't _usually_ use the *+<some value>. I normally use a label with
the &SYSNDX symbol embedded somewhere in it. But I didn't want to "muddy
the waters", and instead make the point that the source operand itself did
not, and possibly should not, be changed.

[Tony Thigpen]

I try to balance the use of B *+2+4 style branches against the
cluttering up by using a bunch of labels. It's never for more than 2
instructions.
Nothing worse than looking at long series of tests followed by bit
setting instructions where every other instruction has a label.

Tony Thigpen

[Ed Jaffe]

On 12/4/2013 12:16 PM, Tony Thigpen wrote:
> Nothing worse than looking at long series of tests followed by bit
> setting instructions where every other instruction has a label.

NILF R1,X'00FF0000'
IF LTR,R1,R1,Z
OI 68(R13),X'80'
ENDIF ,

IF TM,68(R13),X'80',O

IILF R1,X'FF0000FF'
SVC 12

ENDIF ,

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

[Steve Comstock]

On 12/4/2013 1:16 PM, Tony Thigpen wrote:
> I try to balance the use of B *+2+4 style branches against the
> cluttering up by using a bunch of labels. It's never for more than 2
> instructions.


> Nothing worse than looking at long series of tests followed by bit
> setting instructions where every other instruction has a label.

Really? Nothing? A startling lack of imagination there.

:-)


-Steve Comstock

[Ott, Jeff]

Hmmm, a huge chunk of code, hundreds of lines say, replicated a time or two in the same source, with subtle minor changes and compile-time conditioned with easily unnoticed uncommented lonely AIF's. Maybe that's worse, but I'm easily chaffed by head fakes. :-)

[Tony Thigpen]

In z/VSE, they charge extra for the IF macro. We don't have them.

Tony Thigpen

-----Original Message -----

[Paul Gilmartin]

On 2013-12-04, at 13:52, Tony Thigpen wrote:

> In z/VSE, they charge extra for the IF macro. We don't have them.
>

Same with z/OS et al.

-- gil

[Tony Harminc]

But there are other -- better, one may argue -- similar macro sets out
there at no charge. Check the CBT site for some of them.

Tony H.

[Rob van der Heij]

John Hartmann's FPLOM library is on
http://vm.marist.edu/~pipeline/#Runtimewhich might take some tinkering
to shape it into something that can be used
on other platforms than CMS. I like it a lot... -Rob

[Tony Harminc]

On 4 December 2013 15:29, Ed Jaffe <edj...@phoenixsoftware.com> wrote:
> On 12/4/2013 12:16 PM, Tony Thigpen wrote:
>>
>> Nothing worse than looking at long series of tests followed by bit
>> setting instructions where every other instruction has a label.
>
>
> NILF R1,X'00FF0000'
> IF LTR,R1,R1,Z
> OI 68(R13),X'80'
> ENDIF ,
>
> IF TM,68(R13),X'80',O
>
> IILF R1,X'FF0000FF'
> SVC 12
> ENDIF ,

Well, sure, but all the ugly generated labels and such are there when
you have to read the listing rather than the source. And there are
times when you have the offset where something program checked, and
the source just won't do.

Not that I don't use structured (structuring?) macros; I do and they
are great. But using both source and listing is like listening to a
piece of music as a whole or as its component parts; it's difficult to
do both at once.

Tony H.

[Tony Thigpen]

Most of the CBT stuff is not easily readable by a VSE shop because of
it's format. I have done it, but it takes running stuff on windows and
going though hoops.

Tony Thigpen

-----Original Message -----

[DASDBILL2]

If everything else were equal (which it probably isn't), code like that sounds like a good reason to use structured Assembler macros.
Bill Fairchild
Franklin, TN

----- Original Message -----

From: "Tony Thigpen" <to...@vse2pdf.com>
To: ASSEMBL...@LISTSERV.UGA.EDU

[DASDBILL2]

Write your own.

Bill Fairchild

Franklin, TN

----- Original Message -----

From: "Tony Thigpen" <to...@vse2pdf.com>
To: ASSEMBL...@LISTSERV.UGA.EDU
Sent: Wednesday, December 4, 2013 2:52:26 PM
Subject: Re: Base-less programming

[Mike La Martina]

I like your response.

Its near impossible to understand the IBM structured macros, but the Mainstar and TMON VTAM versions were quite understandable, at least to me.

At ASG TIMS used the IBM versions, as did the manager of TMVT, but Parker, walker carter et. al. hate them.

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU] On Behalf Of DASDBILL2
Sent: Wednesday, December 04, 2013 2:16 PM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: Base-less programming

[DASDBILL2]

Write your own structured Assembler macros, and do it without labels.  E.g., you can code either BZ xyz&SYSNDX or you can code BZ *+84 inside a macro.

Bill Fairchild

Franklin, TN

----- Original Message -----

From: "Tony Harminc" <to...@harminc.com>
To: ASSEMBL...@LISTSERV.UGA.EDU
Sent: Wednesday, December 4, 2013 3:37:56 PM
Subject: Re: Base-less programming

[Jon Perryman]

Implementing relative instructions into your macro's won't buy you much. In fact, you can skip this step until you make your programs optimized to using relative instruction by including "COPY IEABRC" at the beginning of the program will change offset branches into relative branches without modifying anything else.

SYSSTATE ARCHLVL=1 or 2 will also make many of the IBM macro's use relative instructions where possible (not all).

I'm not saying you shouldn't use relative instructions in macro's. I'm saying that you'll get value from modifying programs that have multiple base regs. If you don't regain any registers, then what value are you getting from relative instructions.

One of the modifications I like is to move the LTORG to physically occur at the beginning of the program so that your base reg still includes the program start. the advantage is that the PSW offset to the base reg matches the assembler listing. In addition, dumps will show the offset to that reg whereas the alternative is no offset or an offset that cannot be easily converted to an assembler listing or version of that program. I also like to limit the base reg to the end of the constants in the program so that you can identify where your program is not correctly using relative offsets.

Jon Perryman. 

>________________________________
> From: John McKown <john.arch...@gmail.com>

[Adam L Johanson]

> Well, sure, but all the ugly generated labels and such are there when
> you have to read the listing rather than the source.

Tony,

I think you might also be referring to all of the inner macro calls
that show up in the listing and can be not-so-easy on the eyes. If so, have
a look at the PCONTROL(NOMCALL) Assembler option. It might be more
far-reaching than what you're looking for since it'll suppress all of the
inner macro calls, but the option can also be turned off and on via PRINT
MCALL and PRINT NOMCALL that should probably be inside a PUSH/POP sequence.

Adam Johanson
IMS System Services Development

[Ed Jaffe]

On 12/4/2013 1:37 PM, Tony Harminc wrote:
> Well, sure, but all the ugly generated labels and such are there when
> you have to read the listing rather than the source. And there are
> times when you have the offset where something program checked, and
> the source just won't do.

We use FLOWASM. Therefore, most listings we read look like what's
pictured on slide 56 of this SHARE presentation:
ftp://phoenixsoftware.com/pub/demo/Structured_Assembler.pdf

[Martin Truebner]

Jon,

>> COPY IEABRC" at the beginning of the program will ....

not in VSE- If Tony wants to, he might download MAKEREL and use
COPY MAKEREL - but he is on a good way and there is no need to use the
(incomplete) IBM solution or mine.

>> ...SYSSTATE ARCHLVL=1 or 2 ...

Well - z/VSE has is not even willing to acknowledged that the relatives
will work on any box a current vse runs on and therefore change i.e.
the STORAGE macro (to what is already available in z/OS).

this is not to mention fun instructions like

ICM R15,8,* make content of R15 negative

(found in DUMP macro)

Did I mention that the posting from Jon kind of "rattled my cage" ;-)

--
Martin

Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de

[Paul Gilmartin]

On 2013-12-04, at 15:01, Tony Thigpen wrote:

> Most of the CBT stuff is not easily readable by a VSE shop because of
> it's format. I have done it, but it takes running stuff on windows and
> going though hoops.
>

XMIT Manager? How many programmers of z/OS, TPF, etc. can exploit
"CBT stuff" without running stuff on Windows (easy: OS X or Linux)
and "going through hoops"? I can fetch and extract CBT stuff using
nothing but z/OS, but it feels a lot like going through hoops.

-- gil

[Ed Jaffe]

On 12/4/2013 2:27 PM, Jon Perryman wrote:
> Implementing relative instructions into your macro's won't buy you much. In fact, you can skip this step until you make your programs optimized to using relative instruction by including "COPY IEABRC" at the beginning of the program will change offset branches into relative branches without modifying anything else.

On z/OS 1.10 and higher, you might consider using IEABRCX instead. Example:

IEABRCX DEFINE Define B-to-J conversion macros
IEABRCX DISABLE (same)

Then you can easily enable/disable only where needed. Example:

IEABRCX ENABLE Enable B-to-J conversion
IKJRLSA POPTANSP Release IKJPARS storage
IEABRCX DISABLE Disable B-to-J conversion

IEABRCX also supports PUSH/POP so you can easily enable/disable the
conversion in a macro without having to know what's going on in the open
code.

None of this works on z/VSE. :-( It's one reason why we do our z/VSE
product assemblies on z/OS.

[Phil Smith III]

Tony Thigpen wrote:

>I try to balance the use of B *+2+4 style branches against the

>cluttering up by using a bunch of labels. It's never for more than 2

>instructions.

I done got larned on me pappy's knee not to do it for more than ONE
instruction, and to use something like:



BE *+8 Some comment

LA R1,1(,R1) Some other comment

*+8 DS 0H



It's cutesy but I find it quite readable. YMMV.



.phsiii

[Tony Harminc]

I used to do that. But one day someone will change the LA to LAY, or
decide to use AFI instead, or insert an instruction. Then it will
DWIS, but not DWIM.

Tony H.

[Phil Smith III]

Tony Harminc wrote:

>I used to do that. But one day someone will change the LA to LAY, or

>decide to use AFI instead, or insert an instruction. Then it will

>DWIS, but not DWIM.

Sure, but I find it a nice compromise between cluttering it up with
single-use labels and making it easy to miss the *+n usage. For me, this
says "Yo, here be dragons, be careful". After that, it's your gun, your foot
(hm, I typed "your gum, your foot", which is irritating, if not quite as
nasty!).



But yeah, using real labels avoids the problem more!

[Jon Perryman]

If you don't want the extra statement then add the label directly to the statement and use it's length.
JE *+L'LA1
LA1 LA R1,1(R1)

JE LA2+L'LA2
LA2 LA R1,1(R1)

Jon Perryman


----- Original Message -----
> From: Phil Smith III <li...@akphs.com>

[Tony Thigpen]

I already have several internal macros where I use PUSH PRINT, PRINT
NOMCALL, and PULL PRINT. They are very handy.

I do have several 'heavy duty' macros that I wrote and maintain, so
neither writing more macros nor using more macros scare me. But, to be
honest, the current IF (and related) macros actually make reading
someone else's code, or debugging it, harder. Macros should make coding
simpler. These do just the opposite.

In other words, I don't like them.

Tony Thigpen

-----Original Message -----

[Tony Thigpen]

FYI, my products are assembled on my linux desktop with Dignus.

While, another company, for which I do some major development work,
performs all assemblies on z/VM.

I have not assembled my VSE code on VSE in years. :-)

Tony Thigpen

-----Original Message -----

[Tony Thigpen]

Mine is always indented and I always include a +x for each instruction
so that if an instruction is changed, they don't have to recalculate the
branch, just update the positional length:
CLC IPRPLPT,FULL0
BNE *+4+6
MVC IPRPLPT,EZRP_BIND_PORT
MVC IPRPFIP6,NAMEV6_IP
CLC IPRPFIP6,QUAD0
BNE *+4+6
MVC IPRPFIP6,EZRP_BIND_IPV6
CLC V4ASV6_ADDR(12),IPRPFIP6

+ LTR R15,R15
+ BNZ *+4+6+4
+ CLC EZSI_APITYPE,=H'3'
+ BE ERRNO_30309


Very easy to spot and much more readable than a "IF" construct.

Tony Thigpen

-----Original Message -----

[Tony Thigpen]

I just took a closer look at page 56 of the presentation. Based on what
I see, I will never want to use FLOWASM. Here is the output from two
adjacent lines:

.0000329A 95F2 A00B 0000000B 58559 � : IF CLI,EMRJES,EQ,EMRJES2
.000032A2 5810 C4F4 0000353C 58573 � : | L R1,=A(J2TDFLDIDX)

Instructions 329E thought 32A1 are hidden. I can handle hidden
instructions in system macros, but not in, what I would consider, open
code where I may have fat-fingered something. I guess I rely too much on
looking at the generated code when debugging.

To each his own.

Tony Thigpen

-----Original Message -----

[Ed Jaffe]

On 12/4/2013 7:28 PM, Tony Thigpen wrote:
> I just took a closer look at page 56 of the presentation. Based on what
> I see, I will never want to use FLOWASM. Here is the output from two
> adjacent lines:
>
> .0000329A 95F2 A00B 0000000B 58559 � : IF CLI,EMRJES,EQ,EMRJES2
> .000032A2 5810 C4F4 0000353C 58573 � : | L R1,=A(J2TDFLDIDX)
>
> Instructions 329E thought 32A1 are hidden.

FLOWASM never hides anything. The slide merely conveys how FLOWASM
implants nested "flow bars" (ala PL/X) to help improve code readability.

What's pictured appears to be just an ordinary LIST(133) HLASM source
listing with PRINT NOGEN in effect. The "missing" four bytes are simply
the JNE instruction generated by the IF macro.

[Tony Thigpen]

Ed,
I am also a proponent of structured programming. Here is just one small
bit of a my ATLS program on z/VSE.

MAIN_LINE SECTION START

PERFORM INITILIZATION_LOGIC
PERFORM READ_CONTROL_CARDS
PERFORM CONNECT_TO_STACK
PERFORM CONNECT_TO_OCEXIT
PERFORM OPEN_CTL
PERFORM INIT_GSK
PERFORM READ_CONTROL_CARDS
PERFORM WAIT_MASTER_ECB
PERFORM DISCONNECT_FROM_OCEXIT
PERFORM DISCONNECT_FROM_STACK

ML_EXIT SECTION EXIT

The SECTION and PERFORM macros are my own. Just part of a group of about
10 macros that let me write 'mostly' structured programs.

Each section has it's own limited addressability. A branch outside of a
perform section will not even assemble. (Error exit routines are in the
base section of the program to allow easy branch exiting upon critical
errors.) restricted usings " USING (MAIN_LINE,X0080),R9 " are really
nice to prevent errors.

Tony Thigpen

-----Original Message -----
From: Ed Jaffe
Sent: 12/04/2013 05:45 PM

[Rob van der Heij]

On 5 December 2013 08:22, Ed Jaffe <edj...@phoenixsoftware.com> wrote:

>
> FLOWASM never hides anything. The slide merely conveys how FLOWASM
> implants nested "flow bars" (ala PL/X) to help improve code readability.
>
> What's pictured appears to be just an ordinary LIST(133) HLASM source
> listing with PRINT NOGEN in effect. The "missing" four bytes are simply
> the JNE instruction generated by the IF macro.
>

We're getting close to religious issues there... a lot depends on your
tools and the problems you need to solve.

I inherited an XEDIT macro that indents my source to reflect nesting of
clauses and statements, so I don't need the HLASM listing for that. When
dealing with the structure of my code, I work on the source alone. My brain
is too small to do 10 levels of nesting and I find relief in a scheme with
nested procedures: http://www.rvdheij.nl/Presentations/2009-s8134.pdf
When I find myself writing an IF clause that spans more than 50 lines of
source, I'm often doing something wrong.

The reason I need the HLASM listing is to dig in a dump or set traces on my
code, so I would like to see those generated instructions including the
ones that are obvious. The other case for the listing is to correct my
misunderstanding of the macro suite.

Rob

[Tony Thigpen]

Ron,
Thanks for the link. This is more in line with my type of writing than
the current IF macros. They might be something I can really use.

Tony Thigpen

-----Original Message -----

[Bob Woodside]

On 12/4/2013 5:27 PM, Jon Perryman wrote:
> I'm not saying you shouldn't use relative instructions in macro's. I'm saying that you'll get value from modifying programs that have multiple base regs. If you don't regain any registers, then what value are you getting from relative instructions.

The relative branch instructions are faster: they don't suffer the
Address Generation Interlock delay that their register-based
counterparts do. So, yes, any program should benefit from converting.

That said, the "COPY IEABRC" technique is probably best for modifying
older programs.

----
Bob Woodside
Woodsway Consulting

[Scott Ford]

Who are we to judge whose technique is best...

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'

[Kirk Talman]

IBM Mainframe Assembler List <ASSEMBL...@LISTSERV.UGA.EDU> wrote on
12/04/2013 10:28:43 PM:

> From: Tony Thigpen <to...@vse2pdf.com>

> Instructions 329E thought 32A1 are hidden. I can handle hidden
> instructions in system macros, but not in, what I would consider, open
> code where I may have fat-fingered something. I guess I rely too much on
> looking at the generated code when debugging.

I'll AMEN that, especially when the macros are old and someone else's. I
support a lot of old ASM with many finger, hoof, nose, ... prints. My
first act after checking a program out of Endevor is to remove all PRINT
NOGEN.

If you can't stand the entrails of mammals, don't be a veterinarian.

-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you

[Scott Ford]

You just don't know what the other person went through or what pressure they were under to create the code you are looking at or changing....

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'

[John Ehrman]

Kirk Talman noted:
>...My first act after checking a program out of Endevor is to remove all
PRINT NOGEN.

No need to change the source; just assemble the program with the PC(GEN)
option; that overrides all PRINT NOGEN statements, including those embedded
in macros that you might not find in a source scan.

John Ehrman

[Scott Ford]

John,

Ty another great tidbit ...I will use this one also

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'

[Ed Jaffe]

On 12/5/2013 10:22 AM, John Ehrman wrote:
> No need to change the source; just assemble the program with the PC(GEN)
> option; that overrides all PRINT NOGEN statements, including those embedded
> in macros that you might not find in a source scan.

This is a great option to use for final product assemblies.

[John McKown]

On Thu, Dec 5, 2013 at 12:04 PM, Scott Ford <scott_...@yahoo.com> wrote:

> You just don't know what the other person went through or what pressure
> they were under to create the code you are looking at or changing....
>

Very true. Where I work, many deadlines are set by government bodies who
are responding to their "constituents" (or lobbists). They do have have any
idea, nor care, about what it takes to write good code. We get a date and a
threat "Do this by mm-dd-yyyy or be fined $$$$$ per day." Not much slack to
do thinks cleanly.

[Tony Thigpen]

Like Obama-care?

:-)

Tony Thigpen

-----Original Message -----

[Bernd Oppolzer]

Cross-Posted to IBM-Main and IBM-ASSEMBLER-List

I believe it has been discussed before:

the term "baseless programming" is an over-simplification.
It should be "an ASSEMBLER programming technique, where the
code area is not covered by base registers" - which requires
separation of code area and data area and relative branch instructions;
take care of your literals.

If you have large code areas, this may save you some registers,
or you may save some time otherwise needed to save and reload
the registers which cover the code area.

I managed to convert most of our inhouse macros in the last few months
to "baseless", including the site-specific SP macros, so now I don't have
restrictions regarding the size of the code areas any more. Of course,
it is not good to have large code areas (small functional blocks are
better),
but if you want to add trace output macros or other test facilities to a
functional block, you don't like it if code area size restrictions
prevent you
from doing it. This was the main reason for my "baseless" effort - I had
to do some maintenance to some very large and very old programs, and
the only way to do it was to add some trace output.

Thanks to Ed Jaffe for the link to the SHARE presentation, BTW.

Kind regards

Bernd




Am 06.12.2013 02:05, schrieb John McKown:
> On Thu, Dec 5, 2013 at 6:09 PM, zMan <zedgar...@gmail.com> wrote:
>
>> Ouch. SO true.
>>
> Yes. In this same vein, but a bit more seriously, why don't we start using
> RI-programming (for Relative & Immediate) or RelImm-programming. Because
> there is _no_ way that I can think of to write _useful_ code which does not
> use at least a few base+displacement instructions. At the very least for
> the incoming parameter list. Well, maybe a random() type program could be
> written without using any base+displacement instructions if it did some
> sort of manipulation of the data returned by the STCKE instruction instead
> of having a seed and basing the current result on the previous one.
>
>

[Bernd Oppolzer]

Just to give some more explanations:

we have at our site some macros, which allow the structuring of large
ASSEMBLER programs in subroutines. There is a mainline, which is
started by a startup macro (let's call it PSTART), which does all the
linkage
conventions and establishes some base registers for the code and
data area. The number of base registers for the code area is not limited,
but normally should not exceed 3, that makes a code area of 12 k.
The registers may be specified on the PSTART macro call.

Then there are subroutine macros, let's say PPROC and PEND.
PPROC establishes two registers for the code area, which limits
each "PROC" to 8k. Again, the registers may be specified on the
the PPROC macro call.

Of course, the registers may be reused for every new PROC. So already
in the past, programs of virtually umlimited size were possible.

Each PROC can have "local" variables that are located behind the
PEND macro and are accessible only from this PROC.

Now:

By converting the PPROC and PEND macros (and all other macros)
to "baseless", I was able to remove the 8k restriction for the PPROC / PEND
blocks, and I only needed one base register, because I didn't need to
cover the code area any more; I only covered the static data area
behind the PEND macro (and limited it to 4k in the normal case).
The code area may grow without limit, as long as the relativ branches
reach their targets.

I hope this gives you an idea what I did when I converted our environment
to "baseless".

Kind regards

Bernd




Am 06.12.2013 15:45, schrieb Scott Ford:
> Bernd,
>
> Ty for your thread. Some of us unfortunately work in multiple languages are of course are getting older, so we may have to ask about a design or concept more than once..yes I am older and I have a condition which makes focusing sometimes difficult...
>
> That being said, my reason for baseless code is eliminating multiple base register usage and maintain ability..am I wrong here ?

>
> Scott ford
> www.identityforge.com
> from my IPAD
>
> 'Infinite wisdom through infinite means'
>
>

>> On Dec 6, 2013, at 9:20 AM, Bernd Oppolzer <bernd.o...@T-ONLINE.DE> wrote:
>>
>> Cross-Posted to IBM-Main and IBM-ASSEMBLER-List
>>
>> I believe it has been discussed before:
>>
>> the term "baseless programming" is an over-simplification.
>> It should be "an ASSEMBLER programming technique, where the
>> code area is not covered by base registers" - which requires
>> separation of code area and data area and relative branch instructions;
>> take care of your literals.
>>
>> If you have large code areas, this may save you some registers,
>> or you may save some time otherwise needed to save and reload
>> the registers which cover the code area.
>>
>> I managed to convert most of our inhouse macros in the last few months
>> to "baseless", including the site-specific SP macros, so now I don't have
>> restrictions regarding the size of the code areas any more. Of course,
>> it is not good to have large code areas (small functional blocks are better),
>> but if you want to add trace output macros or other test facilities to a
>> functional block, you don't like it if code area size restrictions prevent you
>> from doing it. This was the main reason for my "baseless" effort - I had
>> to do some maintenance to some very large and very old programs, and
>> the only way to do it was to add some trace output.
>>
>> Thanks to Ed Jaffe for the link to the SHARE presentation, BTW.
>>
>> Kind regards
>>
>> Bernd
>>
>>
>>

>> ----------------------------------------------------------------------
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>>

[Scott Ford]

Bernd,

I have a rather large exit that I want to convert. It's the RACF command exit, so I am trying to decide to convert it to baseless or write an assembler stub and redo the exit in C.

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'

[Ed Jaffe]

On 12/6/2013 9:53 AM, Scott Ford wrote:
> I have a rather large exit that I want to convert. It's the RACF command exit, so I am trying to decide to convert it to baseless or write an assembler stub and redo the exit in C.

If you use SPC or METAL C you should not need an assembler stub.

[Scott Ford]

Ed,

That would be superb news, I will have to dig through the Metal C doc. I gave written some C all ready so "learning curve" time.

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'

[Paul Gilmartin]

On 2013-12-06, at 11:16, Scott Ford wrote:
>
> That would be superb news, I will have to dig through the Metal C doc. I gave written some C all ready so "learning curve" time.
>

I understand that not all of the ANSI Standard Library functions
are available in Metal C. But it sounds as if your background is
such that you won't terribly miss them.

-- gil

[Dave Rivers]

Not too beat a horse too much… but you can also do this
with Dignus Systems/C.

- Dave Rivers -

--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

On Dec 6, 2013, at 1:00 PM, Ed Jaffe <edj...@phoenixsoftware.com> wrote:

[Scott Ford]

Gil,

Yeah thanks, I have time so I am not in a time crunch thank goodness. Plus I have looked at some of the older Xephon pubs there are a few C samples etc including mixed languages. So research, then prototype, rinse , lather, repeat ..lol

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'

[Ed Jaffe]

On 12/5/2013 4:44 AM, Tony Thigpen wrote:
> Thanks for the link. This is more in line with my type of writing than
> the current IF macros. They might be something I can really use.

I looked at PL/j a while back (under z/VM 5.3 I think) after Rob told me
about it at a SHARE conference. Its SPMs are conceptually very similar
to HLASM's and PL/j comes with a lot of other niceties like entry/exit
macros, save areas management macros, bit twiddling macros, and even a
code formatter written in z/VM REXX.

For advocates of structured programming, any SPM set is better than
none. PL/j is a nice "language" and, best of all, the price is right for
existing z/VM users! :-)

FYI the FLOWASM source and library exits -- which support z/OS, z/VM and
z/VSE -- will do their "magic" with any structured programming macro set
and even with non-structured programming models that depend on source
code indentation heuristics.

[Capps, Joey]

I will be out of the Office until next Wednesday - Dan Smith is in charge in my place.

Dan Smith
COE Owner for DataReplication |
Team Lead, Principal Subject Matter Expert |
GCS for PowerExchange and DataReplication
Email: dsm...@informatica.com<mailto:dsm...@informatica.com>
Office: +1.512.795.6988


Thanks,
Joey


Thanks,
Joey

[Lloyd Fuller]

All of the functions are NOT available in Metal C, and the ones that are available vary by release (i.e., more are available in z/OS 1.12 than were in 1.10).
 
In addition, if you are writing cross release software products be aware that you need to statically build the Metal C library into your module if you are going from 1.12 back to earlier releases.  BT and shot myself in the foot.
 
Note also that you can use some of the GCC MVS functions with Metal C to provide some of the functionality that does not exist.  For example, the time LE functions are not part of Metal C.  But some of the GCC MVS time functions work quite well with Metal C programs.
 
Lloyd

>________________________________
> From: Paul Gilmartin <PaulGB...@aim.com>
>To: ASSEMBL...@LISTSERV.UGA.EDU
>Sent: Friday, December 6, 2013 1:26 PM
>Subject: Re: Base-less programming

[Micheal Butz]

Sent from my iPhone

> On Dec 5, 2013, at 9:43 AM, Kirk Talman <rkue...@tsys.com> wrote:
>