BAL/BALR vs BAS/BASR in CICS macros 
Author Message
 BAL/BALR vs BAS/BASR in CICS macros

I have noticed that a client's CICS 4.1 macro library has DFHEIxxx
macros that have BAL and BALR instructions rather than BAS and BASR
instructions.  As the PoPs manual points out, there is atleast a small
performance penalty for using BAL instead of BAS (even in 31 bit mode).

Why does IBM continue to ship CICS with macros in this form.  Are there
dependencies in CICS, dependencies in major products from other vendors, or
just a fear of dependencies in application code using CICS?

Surely IBM has not overlooked this set of macros.  Does anyone know why they
remain in the shipping product.   Are there alternative macro libs which use
BAS/BASR instructions?

Robert Rayhawk



Sat, 14 Oct 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros

Inertia and bad habbits. There are still a bazillion macros and modules out
there that haven't been touched since the last ice age and since they're not
actually broken, they will (probably) never be fixed.

On the bad habbits side, most of the asm programmers I know still code BAL
and BALR out of habbit. Its the thing they learn first and somehow they
never seem to adjust. POPS does mention a performance difference, but I
don't believe its very significant, although someone from the 705 building
(Pok) may know more.

I always code the "modern" versions and I use an ISPF edit macro to coerce
all of the old ones in any program I touch - but then I'm fussy and hey,
they've only been around since XA, ya never know when you might run into a
box than doesn't know how to execute a BASR ;o)


Quote:
>Surely IBM has not overlooked this set of macros.  Does anyone know why
they
>remain in the shipping product.   Are there alternative macro libs which
use
>BAS/BASR instructions?



Sat, 14 Oct 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros

Quote:

[snip]
> On the bad habbits side, most of the asm programmers I know still code BAL
> and BALR out of habbit. Its the thing they learn first and somehow they
> never seem to adjust. POPS does mention a performance difference, but I

[snip]

  With ESA/390 you also got BAKR + PR. I use these exclusively these
days.
  But I don't know if I should worry about performance ??
  Any comments ?

  MTIA,
  Per Jessen



Sat, 14 Oct 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros

Quote:

> I always code the "modern" versions and I use an ISPF edit macro to coerce
> all of the old ones in any program I touch - but then I'm fussy and hey,
> they've only been around since XA, ya never know when you might run into a
> box than doesn't know how to execute a BASR ;o)

Not so; they were around before XA. Track down a copy of the 360/67
Functional Specifications.

--

        Shmuel (Seymour J.) Metz
        Senior Software SE
        EDS

The values in From are for the benefit of spammers:
reply to domain exse01.exch.eds.com, user seymour.metz.



Sat, 14 Oct 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros


(snip regarding BASR and related instructions.)

Quote:
>Not so; they were around before XA. Track down a copy of the 360/67
>Functional Specifications.

I have a Green card with them on, marked as 360/67 only, but they are
not in 360 Principles of Operation, or in GC-7000-2 version of 370 POp.

Is it the same opcode and same definition as the 360/67 version?

-- glen



Sat, 14 Oct 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros

Quote:

> Inertia and bad habbits. There are still a bazillion macros and modules out
> there that haven't been touched since the last ice age and since they're not
> actually broken, they will (probably) never be fixed.

There are *some* things that the BAL[R] does differently than the BAS[R].
Most notably, the BAL[R] could be used determine a different calling type.
For example, if the callER uses BAL to link to some thing, the "thing" in
this case can inspect the instruction length code in the linkage register
to determine whether if call was made with BAL or BALR and take appropriate
action. This of course became useless with XA and "above the line" stuff.

Quote:
> On the bad habbits side, most of the asm programmers I know still code BAL
> and BALR out of habbit.

At least through PL/X 1.4, they were still generating BAL/BALR  

Quote:
> ya never know when you might run into a
> box than doesn't know how to execute a BASR ;o)

Not too likely unless you've got an old 3033 powered up and running.

And as an aside, there is *NO* performance difference between the
two forms of link instructions. (Notice I did not say BAKR/PR! Those
two used to be a terrible hit on performance, don't know how they
fare now)

Along with the 360/67, and in the same era the 360/20 and a 360/25
running in 20-mode (duh!) used BAS/BASR as well.

All Amdahl systems since day-1 have had the instructions. It was with
macrocode that they were enabled.



Sat, 14 Oct 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros

The opcodes are the same.  The definitions are essentially the same.
The /67 called the instruction Branch And Store--the current
architecture calls it Branch And Save.  The /67 did 32-bit addressing
rather than 31-bit addressing so the meaning of "saves bits 32-63 of the
current PSW" is slightly different (i.e. the /67 didn't do AMODE is the
sense that ESA does--a separate PSW bit controlled 24-32 bit
addressing).  Interestingly, LRA also existed on the /67 for the same
purpose as later machines with the same opcode.  Note that the 360/67
(yes, it *was* a 360) was a mid-1960s machine!  (Of course, there were
only about a dozen sold...)

Bob

Quote:

> I have a Green card with them on, marked as 360/67 only, but they are
> not in 360 Principles of Operation, or in GC-7000-2 version of 370 POp.

> Is it the same opcode and same definition as the 360/67 version?

> -- glen



Sat, 14 Oct 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros

. . .

Quote:
>I always code the "modern" versions and I use an ISPF edit macro to coerce
>all of the old ones in any program I touch - but then I'm fussy and hey,
>they've only been around since XA, ya never know when you might run into a
>box than doesn't know how to execute a BASR ;o)

I've seen code that used OPSYN to convert BAL/BALR contained in macros
into BAS/BASR.

Andy Wood



Sat, 14 Oct 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros

As a side not, be aware that you can an assembler neumonic can be resassigned to a
different assembler neumonic.  An example in this situation would be to direct the assemler
to used BAS BASR for source occurances of BAL BALR.

So.... no tellin' what's really their at assembler time (at least for the IBM OCO stuff).


Quote:
>I have noticed that a client's CICS 4.1 macro library has DFHEIxxx
>macros that have BAL and BALR instructions rather than BAS and BASR
>instructions.  As the PoPs manual points out, there is atleast a small
>performance penalty for using BAL instead of BAS (even in 31 bit mode).

>Why does IBM continue to ship CICS with macros in this form.  Are there
>dependencies in CICS, dependencies in major products from other vendors, or
>just a fear of dependencies in application code using CICS?

>Surely IBM has not overlooked this set of macros.  Does anyone know why they
>remain in the shipping product.   Are there alternative macro libs which use
>BAS/BASR instructions?

>Robert Rayhawk


John Schlatweiler
Senior Technical Specialist / Information Management Officer
Mercantile Bank


All views expressed here belong to someone.



Sat, 14 Oct 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros

:As a side not, be aware that you can an assembler neumonic can be
resassigned
:to a different assembler neumonic.  An example in this situation would
be to
:direct the assemler to used BAS BASR for source occurances of BAL BALR.

I apologize in advance for being too picky, but "neumonic" grates on my
eyes AND ears.  It's "mnemonic".



Sat, 14 Oct 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros

Quote:

> I have a Green card with them on, marked as 360/67 only, but they are
> not in 360 Principles of Operation, or in GC-7000-2 version of 370 POp.

Bob's article pretty much says it all. Note that PoOps rarely has
model-spacific opcodes.

BTW, if you read the description of the microcode on the 370/165 you
will find that there was provision for testing whether the machine was
running in 32-bit mode. It makes me curious as to what they originally
did XA on.

--

        Shmuel (Seymour J.) Metz
        Senior Software SE
        EDS

The values in From are for the benefit of spammers:
reply to domain exse01.exch.eds.com, user seymour.metz.



Mon, 16 Oct 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros

I'll swear I saw this reply once already, but I'll reply to it anyhow
since something has occurred to me.  I was once told that TSS was indeed
implemented on the 370 platform.  Perhaps that's why the 32-bit ucode
test existed?

Bob


Quote:

> <snip>

> BTW, if you read the description of the microcode on the 370/165 you
> will find that there was provision for testing whether the machine was
> running in 32-bit mode. It makes me curious as to what they originally
> did XA on.

> --

>         Shmuel (Seymour J.) Metz
>         Senior Software SE
>         EDS



Sat, 28 Oct 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros

Quote:

> I'll swear I saw this reply once already, but I'll reply to it anyhow
> since something has occurred to me.  I was once told that TSS was indeed
> implemented on the 370 platform.  Perhaps that's why the 32-bit ucode
> test existed?


> > BTW, if you read the description of the microcode on the 370/165 you
> > will find that there was provision for testing whether the machine was
> > running in 32-bit mode. It makes me curious as to what they originally
> > did XA on.

First, TSS ran very well on 370-class systems. Most notably the Amdahl
V8 series, as well as 3033MP/AP processors. They had six of them at
one of the older Bell Lab (now Lucent Tech) sites near Chicago running
TSS/370.

According to one of my sources, XA was a joint venture, of sorts
between the MVS dev group and hardware microcode. The first machine
to run what is now known as XA was a 3081K (I think?). The first
machine I ran it on was a 3083 - 1/2 of a 81.

--
Bill



Wed, 01 Nov 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros

Quote:

> First, TSS ran very well on 370-class systems. Most notably the Amdahl
> V8 series, as well as 3033MP/AP processors. They had six of them at
> one of the older Bell Lab (now Lucent Tech) sites near Chicago running
> TSS/370.

As I recall TSS/370 went through 3 releases, but I don't recall it
supporting addresses larger than 24 bits. Was that support ever ported
to S/370?

Quote:
> According to one of my sources, XA was a joint venture, of sorts
> between the MVS dev group and hardware microcode. The first machine
> to run what is now known as XA was a 3081K (I think?). The first
> machine I ran it on was a 3083 - 1/2 of a 81.

While MVS/XA was announced for the 3081, that doesn't mean that IBM
didn't have it up in the lab on an earlier machine. I'd be curious as to
what their first test machine was.


Fri, 03 Nov 2000 03:00:00 GMT  
 BAL/BALR vs BAS/BASR in CICS macros


Quote:


> > First, TSS ran very well on 370-class systems. Most notably the Amdahl
> > V8 series, as well as 3033MP/AP processors. They had six of them at
> > one of the older Bell Lab (now Lucent Tech) sites near Chicago running
> > TSS/370.

> As I recall TSS/370 went through 3 releases, but I don't recall it
> supporting addresses larger than 24 bits. Was that support ever ported
> to S/370?

Not to my knowledge. Although "conceptually" TSS had 32 bit addressing
right out of the shute. It was kind-of half-heartedly supported via an
I/O and memory addressing scheme that can be likened to modern day DIV,
but it was up to the user to manage these "segments" as they were called.

 > According to one of my sources, XA was a joint venture, of sorts

Quote:
> > between the MVS dev group and hardware microcode. The first machine
> > to run what is now known as XA was a 3081K (I think?). The first
> > machine I ran it on was a 3083 - 1/2 of a 81.

> While MVS/XA was announced for the 3081, that doesn't mean that IBM
> didn't have it up in the lab on an earlier machine. I'd be curious as to
> what their first test machine was.

Don't know...

--
Bill



Fri, 03 Nov 2000 03:00:00 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. BAL vs BAS

2. BALR,BASR

3. HOMEWORK****CICS/BAL/COBOL*****

4. HOMEWORK****CICS/BAL/COBOL*****

5. macro -vs- macro/codeblock

6. New CICS removes Translator support for VS COBOL II (and OS/VS COBOL)

7. description/explanation of CICS macros

8. Macro-level CICS Registers?

9. CICS MACRO LEVEL IN ASSEMBLER

10. CICS/PL1 Macro- to Cmd-lvl Conversion Consultants?

11. description/explanation of CICS macros

12. CICS Macro->Command

 

 
Powered by phpBB® Forum Software