Sent from my iPhone
> On Dec 5, 2013, at 9:43 AM, Kirk Talman wrote:
>
> IBM Mainframe Assembler List wrote on
> 12/04/2013 10:28:43 PM:
>
>> From: Tony Thigpen
>
>> Instructions 329E thought 32A1 are hidden. I can handle hidden
>> instructions in system macros, but not in, what I would conside
of the GCC MVS time functions
work quite well with Metal C programs.
Lloyd
>
> From: Paul Gilmartin
>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>Sent: Friday, December 6, 2013 1:26 PM
>Subject: Re: Base-less programming
>
>
>On 2013-12-06, at
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
'Infi
Not too beat a horse too much… but you can also do this
with Dignus Systems/C.
- Dave Rivers -
--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
On Dec 6, 2013, at 1:00 PM, Ed Jaffe wrote:
> On 12/6/2013 9:53 A
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 b
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'
> On Dec 6, 2013, at 1:00 PM, Ed Jaffe wrote:
>
>> On 12/6/2013 9:53 AM,
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.
--
Edw
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'
> On Dec 6, 2013,
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
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
Like Obama-care?
:-)
Tony Thigpen
-Original Message -
From: John McKown
Sent: 12/05/2013 07:57 PM
On Thu, Dec 5, 2013 at 12:04 PM, Scott Ford 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 cha
On Thu, Dec 5, 2013 at 12:04 PM, Scott Ford 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
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 asse
John,
Ty another great tidbit ...I will use this one also
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
> On Dec 5, 2013, at 1:22 PM, John Ehrman wrote:
>
> Kirk Talman noted:
>> ...My first act after checking a program out of Endevor is to remove all
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 sour
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'
> On Dec 5, 2013, at 9:43 AM, Kirk Talman wrote:
>
> IBM Mainfra
IBM Mainframe Assembler List wrote on
12/04/2013 10:28:43 PM:
> From: Tony Thigpen
> 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
Who are we to judge whose technique is best...
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
> On Dec 5, 2013, at 8:27 AM, Bob Woodside wrote:
>
>> On 12/4/2013 5:27 PM, Jon Perryman wrote:
>> I'm not saying you shouldn't use relative instructions in ma
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.
T
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 -
From: Rob van der Heij
Sent: 12/05/2013 04:43 AM
On 5 December 2013 08:22, Ed Jaffe wrote:
FLOWASM never hi
On 5 December 2013 08:22, Ed Jaffe 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 effec
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 OP
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:
.329A 95F2 A00B 000B 58559 ¦ : IF CLI,EMRJES,EQ,EMRJES2
.32A2 5810 C4F4 353C 5857
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:
.329A 95F2 A00B 000B 58559 ¦ : IF CLI,EMRJES,EQ,EMRJES2
.32A2 5810 C4F4 353C 58573 ¦ : | L R1,=A(J2TDFLDIDX)
Instructions 3
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 IPRP
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 -
From: Ed Jaffe
Sent: 12/04/2013
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
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
>
>T ony Harminc wrote:
>
>> I used to do
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 th
On 4 December 2013 18:16, Phil Smith III wrote:
> 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
> ins
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
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
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" witho
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
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. Theref
> 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 th
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 modi
ent: Wednesday, December 4, 2013 3:37:56 PM
Subject: Re: Base-less programming
On 4 December 2013 15:29, Ed Jaffe 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
Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of DASDBILL2
Sent: Wednesday, December 04, 2013 2:16 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less programming
If everything else were equal (which it probably isn't), code like
Write your own.
Bill Fairchild
Franklin, TN
- Original Message -
From: "Tony Thigpen"
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Sent: Wednesday, December 4, 2013 2:52:26 PM
Subject: Re: Base-less programming
In z/VSE, they charge extra for the IF macro. We don't ha
4, 2013 2:16:41 PM
Subject: Re: Base-less programming
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 instructio
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 -
From: Tony Harminc
Sent: 12/04/2013 04:30 PM
On 4 December 2013 15:56, Paul Gilmartin wrot
On 4 December 2013 15:29, Ed Jaffe 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'00FF'
> IF LTR,R1,R1,Z
>OI 68(
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
On 4 December 2013 22:30, Tony Harminc wrote:
> On 4 December 2013 15:56, Paul Gilmartin w
On 4 December 2013 15:56, Paul Gilmartin wrote:
> 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.
But there are other -- better, one may argue -- similar macro sets out
there at no charge. Check the CBT
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
In z/VSE, they charge extra for the IF macro. We don't have them.
Tony Thigpen
-Original Message -
From: Ed Jaffe
Sent: 12/04/2013 03:29 PM
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 o
riginal Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Comstock
Sent: Wednesday, December 04, 2013 12:32 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Base-less programming
On 12/4/2013 1:16 PM, Tony Thigpen wrote:
> I try to balance
Base-less programming
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> >
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 com
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'00FF'
IF LTR,R1,R1,Z
OI 68(R13),X'80'
ENDIF ,
IF TM,68(R13),X'80',O
I
igpen
-Original Message -
From: Chris Craddock
Sent: 12/04/2013 02:58 PM
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
> >
Am I reading the book right?
No. Although the assembled instru
On Wed, Dec 4, 2013 at 1:58 PM, Chris Craddock wrote:
> > 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
> >
> > >
> > > Am I readin
> 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
>
> >
> > Am I reading the book right?
> >
>
> No. Although the assembled instructions have the displac
BO
BRO
JO
BNO
BRNO
JNO
BZ
BRZ
JZ
BNZ
BRNZ
JNZ
IBM Mainframe Assembler List wrote on
12/04/2013 02:29:33 PM:
> From: Tony Thigpen
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU,
> Date: 12/04/2013 02:32 PM
> Subject: Base-less programming
> Sent by: IBM Mainframe Assembler List
>
>
On Wed, Dec 4, 2013 at 1:29 PM, Tony Thigpen wrote:
> I am doing my first attempt at modifying an internal macro to be
> baseless. The first two examples are:
>
> NILF R1,X'00FF'
> LTR R1,R1
> BNZ *+4+4
> OI 68(R13),X'80'
>
>
> TM68(R1
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
I am doing my first attempt at modifying an internal macro to be
baseless. The first two examples are:
NILF R1,X'00FF'
LTR R1,R1
BNZ *+4+4
OI 68(R13),X'80'
TM68(R13),X'80'
BNO *+4+6+2
IILF R1,X'FFFF'
57 matches
Mail list logo
