Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-08-02 Thread Shmuel Metz (Seymour J.)
In
<9f0ac04eb56ec643bdb1b36ab0c34583e12...@hdqsrvexcvs.ssfcuad.ssfcu.org>,
on 08/01/2011
   at 09:27 AM, "Ward, Mike S"  said:

>Gerhard, I'm sorry for laughing at your post, but it struck me as
>funny. Did you really mean to say masticate?

Almost certainly. The point was that the politician was allegedly
using words that his uneducated constituency was unlikely to recognize
in order to mislead them.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-08-01 Thread Gerhard Postpischil

On 8/1/2011 10:27 AM, Ward, Mike S wrote:

Gerhard, I'm sorry for laughing at your post, but it struck me as funny.
Did you really mean to say masticate?


Yes, that's how I remembered it. Unfortunately others don't. See 
http://en.wikipedia.org/wiki/Claude_Pepper


Part of American political lore is the Smathers "redneck 
speech," which Smathers reportedly delivered to a poorly 
educated audience. The "speech" was never given; it was a hoax 
dreamed up by one reporter. Smathers did not say, as was 
reported in Time Magazine during the campaign:


Are you aware that Claude Pepper is known all over 
Washington as a shameless extrovert? Not only that, but this man 
is reliably reported to practice nepotism with his 
sister-in-law, he has a brother who is a known homo sapiens,[7] 
and he has a sister who was once a thespian in wicked New York. 
Worst of all, it is an established fact that Mr. Pepper, before 
his marriage, habitually practiced celibacy.[8]


The Smathers campaign denied his having made the speech, as did 
the reporters who covered his campaign, but the hoax followed 
Smathers to his death.[9]



Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-08-01 Thread Ted MacNEIL
>Did you really mean to say masticate?

He probably did.

It means "chew", and it's an old joke.

http://en.wikipedia.org/wiki/Masticate

Now, pardon me while I go ablute myself.

(http://www.allwords.com/word-ablute.html)
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-08-01 Thread Ward, Mike S
Walk and chew gum at the same time?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Rick Fochtman
Sent: Sunday, July 31, 2011 8:39 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

--
-- 


>>  My opponent has publicly
>> matriculated and his father was a thespian.
>
>
> Not the way I heard it: he was seen to masticate in public, and his 
> sister was a thespian. There was also a third one I can't recall.
>

---
Yes, but can he masticate and perambulate at the same time?  :-)  I 
think the third one was a gypsy prognosticator, but not a very good 
one.  :-)

Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

==
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity
to which they are addressed. If you have received this email in error please 
notify the system manager. This message
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the 
sender immediately by e-mail if you
have received this e-mail by mistake and delete this e-mail from your system. 
If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this
information is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-08-01 Thread Ward, Mike S
Gerhard, I'm sorry for laughing at your post, but it struck me as funny.
Did you really mean to say masticate?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Gerhard Postpischil
Sent: Sunday, July 31, 2011 9:23 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

On 7/31/2011 9:37 AM, Shmuel Metz (Seymour J.) wrote:
>  My opponent has publicly
> matriculated and his father was a thespian.

Not the way I heard it: he was seen to masticate in public, and 
his sister was a thespian. There was also a third one I can't 
recall.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

==
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity
to which they are addressed. If you have received this email in error please 
notify the system manager. This message
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the 
sender immediately by e-mail if you
have received this e-mail by mistake and delete this e-mail from your system. 
If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this
information is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-31 Thread Rick Fochtman
 




 My opponent has publicly
matriculated and his father was a thespian.



Not the way I heard it: he was seen to masticate in public, and his 
sister was a thespian. There was also a third one I can't recall.



---
Yes, but can he masticate and perambulate at the same time?  :-)  I 
think the third one was a gypsy prognosticator, but not a very good 
one.  :-)


Rick

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-31 Thread Gerhard Postpischil

On 7/31/2011 9:37 AM, Shmuel Metz (Seymour J.) wrote:

 My opponent has publicly
matriculated and his father was a thespian.


Not the way I heard it: he was seen to masticate in public, and 
his sister was a thespian. There was also a third one I can't 
recall.



Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-31 Thread Shmuel Metz (Seymour J.)
In , on 07/25/2011
   at 01:18 PM, "Robert A. Rosenberg"  said:

>It was the use of the description (and misleading 
>descriptions of the effects and usage) to convince people to sign 
>petitions to ban its use that makes it part of a hoax

Relying on the ignorance of your listeners or readers does not make an
accurate description into a hoax. My opponent has publicly
matriculated and his father was a thespian.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-25 Thread Robert A. Rosenberg
At 02:33 -0400 on 07/24/2011, Shmuel Metz (Seymour J.) wrote about 
Re: running Assembler I/O macro code as AMODE 31, RMODE ANY:



 >The description above was part of a hoax

Wiki refers to it as a hoax, but I don't see it as any more of a hoax
than the famous sign offering access to the egress. In fact, the DHMO
site does not match wiki's own definition[1] of hoax

[1] <http://en.wikipedia.org/wiki/Hoax>


Note that I stated "Part of a Hoax" not that it was in-and-of-itself 
a hoax. The description while worded to give a desired impression had 
all of the stated facts being accurately made. Thus it is not itself 
necessary a hoax. It was the use of the description (and misleading 
descriptions of the effects and usage) to convince people to sign 
petitions to ban its use that makes it part of a hoax (ie: The 
petition being the hoax). If the common name of DHMO was used in lieu 
of DHMO in the descriptions it would be just as accurate but the 
impression given by the statement of facts would be different (IOW: 
The deliberate use of DHMO in lieu of the common name for the 
substance makes listing into hoax - not due to the stated facts but 
due to the way they are presented by using DHMO to disguise the 
identity of the substance).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-24 Thread Chris Hoelscher
In fact there are to versions of the DHMO website  - the hard-hitting site, and 
a . watered -down version for the feint-of-heart

Chris Hoelscher
IDMS & DB2 Database Administrator
502-476-2538

You only need to test the programs you don't want to get called on later


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Bill Fairchild
Sent: Sunday, July 24, 2011 2:11 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] running Assembler I/O macro code as AMODE 31, RMODE ANY

Hoax or not, the fact remains that DHMO is an extremely dangerous and volatile 
substance.  Why, even when repeatedly and heavily diluted, to as weak a 
solution as one part in hundreds of trillions,  the substance is just as 
dangerous as it is in its pure form.  E.g., DHMO in any strength has been known 
to break down explosively when it comes in contact with many other common 
substances, such as lithium, sodium, and potassium, the last two of which are 
commonly found in all human bodies.  And enormous amounts of heat are given off 
when DHMO comes in contact with lime and dry concrete mix, which are found in a 
large percent of American households and in all Home Depot stores.  Do the Home 
Depot stockholders know about this?

Bill Fairchild 



The information transmitted is intended only for the person or entity to which 
it is addressed and may contain CONFIDENTIAL material.  If you receive this 
material/information in error, please contact the sender and delete or destroy 
the material/information.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-24 Thread Bill Fairchild
Hoax or not, the fact remains that DHMO is an extremely dangerous and volatile 
substance.  Why, even when repeatedly and heavily diluted, to as weak a 
solution as one part in hundreds of trillions,  the substance is just as 
dangerous as it is in its pure form.  E.g., DHMO in any strength has been known 
to break down explosively when it comes in contact with many other common 
substances, such as lithium, sodium, and potassium, the last two of which are 
commonly found in all human bodies.  And enormous amounts of heat are given off 
when DHMO comes in contact with lime and dry concrete mix, which are found in a 
large percent of American households and in all Home Depot stores.  Do the Home 
Depot stockholders know about this?

Bill Fairchild

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Sunday, July 24, 2011 1:34 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

In , on 07/23/2011
   at 04:59 PM, "Robert A. Rosenberg"  said:

>The description above was part of a hoax

Wiki refers to it as a hoax, but I don't see it as any more of a hoax than the 
famous sign offering access to the egress. In fact, the DHMO site does not 
match wiki's own definition[1] of hoax

[1] <http://en.wikipedia.org/wiki/Hoax>
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-23 Thread Shmuel Metz (Seymour J.)
In , on 07/23/2011
   at 04:59 PM, "Robert A. Rosenberg"  said:

>The description above was part of a hoax

Wiki refers to it as a hoax, but I don't see it as any more of a hoax
than the famous sign offering access to the egress. In fact, the DHMO
site does not match wiki's own definition[1] of hoax

[1] 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-23 Thread Robert A. Rosenberg
At 16:37 -0400 on 07/22/2011, Shmuel Metz (Seymour J.) wrote about 
Re: running Assembler I/O macro code as AMODE 31, RMODE ANY:



 >http://www.dhmo.org/facts.html

But DHMO is a real compound, and the dangers cited are real.


Just (as I posted in a message that crossed with this one) described 
in an over the top manner that makes it seem to be very dangerous if 
you are not aware of this substance's more normal name (Hint: Convert 
the name into a chemical formula which should then be an alias for 
the common name).


The description above was part of a hoax with a listing of the very 
real negative effects of this chemical, in a mock attempt to convince 
people that it should be carefully regulated, labeled as hazardous, 
or banned. For details, see http://en.wikipedia.org/wiki/DHMO_hoax.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Robert A. Rosenberg
At 08:28 -0400 on 07/22/2011, David Andrews wrote about Re: running 
Assembler I/O macro code as AMODE 31, RMODE ANY:



Tells you something about a group of people when one guy mentions
thiotimoline and nobody bats an eyelash.


Isaac would be proud to have invented something that everyone (aside 
from SciFi fans) are aware of and can recognize. Usually it is his 3 
Laws that fall into this category.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Robert A. Rosenberg
At 09:01 -0500 on 07/22/2011, Eric Bielefeld wrote about Re: running 
Assembler I/O macro code as AMODE 31, RMODE ANY:


OK - I'll bite.  What is thiotimoline?  I saw it earlier and just 
ignored it, but now I'm curious.


See http://en.wikipedia.org/wiki/Thiotimoline. Basically Science 
Fiction Author Isaac Asimov was getting ready to write his Doctoral 
Thesis and was worried that all of his writing of SciFi stories would 
impact his ability to use the correct Thesis style for his actual 
Thesis. So he wrote (and published) a story in the required style to 
practice. As an anecdote when he actually took his orals the 
examiners signalled him that he passed by making their last question 
a request for a comment on thiotimoline (something that would not be 
proper if they would going to fail him).


As to your question, it is a fictional substance that dissolves in 
water. The special property is that it dissolves up to a second or so 
BEFORE the water is added. The paper covers this property and 
explains it as well as what happens if after seeing it dissolve the 
water is not added. He went on to write additional stories/papers on 
this substance (details in the Wikipedia article above).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Shmuel Metz (Seymour J.)
In <2FE099896A804AA4859582BC3A930C07@ericnbPC>, on 07/22/2011
   at 09:01 AM, Eric Bielefeld  said:

>OK - I'll bite.  What is thiotimoline?

A fictitious compound with four bonds at right angles to each other.
It dissolves in water a fraction of a second before you add the water,
making it highly dangerous. Try to withhold the water after the
thiotimoline dissolves and water will arrive from elsewhere, even if
it takes an unlikely flood to get it there.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Shmuel Metz (Seymour J.)
In <45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc>, on
07/22/2011
   at 09:29 AM, "Staller, Allan"  said:

>http://www.dhmo.org/facts.html

But DHMO is a real compound, and the dangers cited are real.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread John Baxter
For the z10: IBM J. RES. & DEV. VOL. 53 NO. 1 PAPER 1 2009 ("Design and
microarchitecture of the IBM System z10 microprocessor"), obtainable
through IEEE by subscription. The z9 version may still be available via
alternate internet sources.

John Baxter
ATCO I-Tek



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Bill Fairchild
Sent: Friday, July 22, 2011 1:07 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

Where do you find such detailed descriptions?  Patent application?
System journal?  NDA material?  You can tell me, but then you'ld have to
kill me?

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Edward Jaffe
Sent: Friday, July 22, 2011 1:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

The last time I thoroughly studied/investigated System z branch
prediction logic
(BPL) was on the z9.

On that model, the BPL runs early in the pipeline, before instruction
decode, and it essentially runs asynchronously to the rest of the
pipeline. It prefetches instructions and predicts direction and target
based on the path it thinks the rest of the pipeline will be later
executing. It puts those prefetched streams into fairly large
instruction buffers awaiting when they might be needed by the decode
logic.

The BPL logic itself uses what appears to be a unified Branch Target
Buffer and Direction Buffer (they are physically built of separate
arrays but are logically the same). The BTB contains 8K entries. Being
clever, IBM decided not to 'remember' not-taken conditional branches,
thus allowing the BTB to appear much bigger than it really is. This was
considered a reasonable performance trade-off (the rationale for keeping
not taken branches in the BTB is to more accurately handle branches that
frequently change direction). The z9 BTB uses a strongly-taken,
weakly-taken approach for each branch.

Another clever thing IBM did on the z9 was to implement "just in time" 
prefetching down non-predicted branch paths to enhance performance. So
if the hardware predicts a branch will be not taken, it prefetches the
taken-path just before the branch direction is resolved in the execution
stage of the pipeline. 
So if it was predicted incorrectly, the taken-path will be in a
"recovery instruction buffer" where it could be sent into the decoder on
the next cycle.

Slick! :-) 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


The information transmitted is intended only for the addressee and may contain 
confidential, proprietary and/or privileged material. Any unauthorized review, 
distribution or other use of or the taking of any action in reliance upon this 
information is prohibited. If you receive this in error, please contact the 
sender and delete or destroy this message and any copies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Bill Fairchild
Where do you find such detailed descriptions?  Patent application?  System 
journal?  NDA material?  You can tell me, but then you'ld have to kill me?

Bill Fairchild
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Edward Jaffe
Sent: Friday, July 22, 2011 1:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

The last time I thoroughly studied/investigated System z branch prediction logic
(BPL) was on the z9.

On that model, the BPL runs early in the pipeline, before instruction decode, 
and it essentially runs asynchronously to the rest of the pipeline. It 
prefetches instructions and predicts direction and target based on the path it 
thinks the rest of the pipeline will be later executing. It puts those 
prefetched streams into fairly large instruction buffers awaiting when they 
might be needed by the decode logic.

The BPL logic itself uses what appears to be a unified Branch Target Buffer and 
Direction Buffer (they are physically built of separate arrays but are 
logically the same). The BTB contains 8K entries. Being clever, IBM decided not 
to 'remember' not-taken conditional branches, thus allowing the BTB to appear 
much bigger than it really is. This was considered a reasonable performance 
trade-off (the rationale for keeping not taken branches in the BTB is to more 
accurately handle branches that frequently change direction). The z9 BTB uses a 
strongly-taken, weakly-taken approach for each branch.

Another clever thing IBM did on the z9 was to implement "just in time" 
prefetching down non-predicted branch paths to enhance performance. So if the 
hardware predicts a branch will be not taken, it prefetches the taken-path just 
before the branch direction is resolved in the execution stage of the pipeline. 
So if it was predicted incorrectly, the taken-path will be in a "recovery 
instruction buffer" where it could be sent into the decoder on the next cycle.

Slick! :-) 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Edward Jaffe

On 7/21/2011 7:19 AM, Shmuel Metz (Seymour J.) wrote:

In<4e24b31c.5080...@phoenixsoftware.com>, on 07/18/2011
at 03:26 PM, Edward Jaffe  said:


Absolutely! There is a multi-stage pipeline that allows the processor
to get ahead of the current instruction's execution to fetch and
decode instructions,  resolve addresses, fetch operands, etc. in
advance of the actual instruction execution.

That doesn't address my question. The questions are when the processor
starts filling in a new segment of the pipeline for a branch and
whether it takes the opcode into account. Keep in mind that there is
not a separate general register for the target address mode.


The last time I thoroughly studied/investigated System z branch prediction logic 
(BPL) was on the z9.


On that model, the BPL runs early in the pipeline, before instruction decode, 
and it essentially runs asynchronously to the rest of the pipeline. It 
prefetches instructions and predicts direction and target based on the path it 
thinks the rest of the pipeline will be later executing. It puts those 
prefetched streams into fairly large instruction buffers awaiting when they 
might be needed by the decode logic.


The BPL logic itself uses what appears to be a unified Branch Target Buffer and 
Direction Buffer (they are physically built of separate arrays but are logically 
the same). The BTB contains 8K entries. Being clever, IBM decided not to 
'remember' not-taken conditional branches, thus allowing the BTB to appear much 
bigger than it really is. This was considered a reasonable performance trade-off 
(the rationale for keeping not taken branches in the BTB is to more accurately 
handle branches that frequently change direction). The z9 BTB uses a 
strongly-taken, weakly-taken approach for each branch.


Another clever thing IBM did on the z9 was to implement "just in time" 
prefetching down non-predicted branch paths to enhance performance. So if the 
hardware predicts a branch will be not taken, it prefetches the taken-path just 
before the branch direction is resolved in the execution stage of the pipeline. 
So if it was predicted incorrectly, the taken-path will be in a "recovery 
instruction buffer" where it could be sent into the decoder on the next cycle.


Slick! :-)





--
Edward E Jaffe
Chief Technology Officer
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Bill Fairchild
I had to ask Mr. Google to find me a definition of it.  Once there, I 
remembered having read the Asimov short story 55 or so years ago.  I just 
didn't remember the name of the protagonist.  :-)

Bill Fairchild

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
David Andrews
Sent: Friday, July 22, 2011 7:29 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

On Tue, 2011-07-19 at 08:30 -0400, Mark Jacobs wrote:
> Sounds almost thiotimoline like to me.

Tells you something about a group of people when one guy mentions
thiotimoline and nobody bats an eyelash.   ;-)

--
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Eric Bielefeld
Thanks.  I was trying to remember if I've ever read anything by Isaac 
Asimov, but I can't remember.  I think I would have remembered if I had read 
one of the stories about Thiotimoline.


Jee - we are really getting off topic, and I'm not helping!

Eric Bielefeld
Sr. Systems Programmer
IBM Global Services Division
Dubuque, Iowa
414-477-7259



- Original Message - 
From: "McKown, John" 


Thiotimoline is a fictitious chemical compound conceived by science 
fiction author Isaac Asimov and first described in a spoof scientific 
paper titled "The Endochronic Properties of Resublimated Thiotimoline" in 
1948. Asimov went on to write three additional short stories, each 
describing different properties or uses of thiotimoline.




--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r) 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Staller, Allan
http://www.dhmo.org/facts.html


Al Staller | Z Systems Programmer | KBM Group | (Tel) 972 664 3565 | 
allan.stal...@kbmg.com




Perhaps not the same as intended but ... it's a fictitious compound
chemical... there were multiple papers written ... but don't think
that the 'actual compound' was ever exposed. 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Chase, John
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Eric Bielefeld
> 
> OK - I'll bite.  What is thiotimoline?  I saw it earlier and just ignored
> it, but now I'm curious.

http://en.wikipedia.org/wiki/Thiotimoline

-jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Jim Thomas
Perhaps not the same as intended but ... it's a fictitious compound
chemical... there were multiple papers written ... but don't think
that the 'actual compound' was ever exposed. 

:-) 


Kind Regards

Jim Thomas
617-233-4130 (mobile)
636-294-1014(res)
j...@thethomasresidence.us (Email)


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Eric Bielefeld
Sent: Friday, July 22, 2011 9:02 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

OK - I'll bite.  What is thiotimoline?  I saw it earlier and just ignored 
it, but now I'm curious.

Eric Bielefeld
Sr. Systems Programmer
IBM Global Services Division
Dubuque, Iowa
414-477-7259



- Original Message - 
From: "David Andrews" 
>
> Tells you something about a group of people when one guy mentions
> thiotimoline and nobody bats an eyelash.   ;-)
>
> -- 
> David Andrews
> A. Duda & Sons, Inc.
> david.andr...@duda.com 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1390 / Virus Database: 1518/3781 - Release Date: 07/22/11

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread McKown, John
Google is your friend.

http://en.wikipedia.org/wiki/Thiotimoline

Thiotimoline is a fictitious chemical compound conceived by science fiction 
author Isaac Asimov and first described in a spoof scientific paper titled "The 
Endochronic Properties of Resublimated Thiotimoline" in 1948. Asimov went on to 
write three additional short stories, each describing different properties or 
uses of thiotimoline.



--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Eric Bielefeld
> Sent: Friday, July 22, 2011 9:02 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> 
> OK - I'll bite.  What is thiotimoline?  I saw it earlier and 
> just ignored 
> it, but now I'm curious.
> 
> Eric Bielefeld
> Sr. Systems Programmer
> IBM Global Services Division
> Dubuque, Iowa
> 414-477-7259
> 
> 
> 
> - Original Message - 
> From: "David Andrews" 
> >
> > Tells you something about a group of people when one guy mentions
> > thiotimoline and nobody bats an eyelash.   ;-)
> >
> > -- 
> > David Andrews
> > A. Duda & Sons, Inc.
> > david.andr...@duda.com 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Eric Bielefeld
OK - I'll bite.  What is thiotimoline?  I saw it earlier and just ignored 
it, but now I'm curious.


Eric Bielefeld
Sr. Systems Programmer
IBM Global Services Division
Dubuque, Iowa
414-477-7259



- Original Message - 
From: "David Andrews" 


Tells you something about a group of people when one guy mentions
thiotimoline and nobody bats an eyelash.   ;-)

--
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread David Andrews
On Tue, 2011-07-19 at 08:30 -0400, Mark Jacobs wrote:
> Sounds almost thiotimoline like to me.

Tells you something about a group of people when one guy mentions
thiotimoline and nobody bats an eyelash.   ;-)

-- 
David Andrews
A. Duda & Sons, Inc.
david.andr...@duda.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Shmuel Metz (Seymour J.)
In <4e24b31c.5080...@phoenixsoftware.com>, on 07/18/2011
   at 03:26 PM, Edward Jaffe  said:

>Absolutely! There is a multi-stage pipeline that allows the processor
>to get ahead of the current instruction's execution to fetch and
>decode instructions,  resolve addresses, fetch operands, etc. in
>advance of the actual instruction execution.

That doesn't address my question. The questions are when the processor
starts filling in a new segment of the pipeline for a branch and
whether it takes the opcode into account. Keep in mind that there is
not a separate general register for the target address mode.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-22 Thread Shmuel Metz (Seymour J.)
In <4e2578d1.7010...@custserv.com>, on 07/19/2011
   at 08:30 AM, Mark Jacobs  said:

>Sounds almost thiotimoline like to me.

Not really, the technology is decades old, but the Devil is in the
details, and so far nobody has provided any. I can conceive of designs
where AMODE switching causes pipeline problems, but not of one that is
plausible.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-19 Thread Mark Jacobs

On 07/18/11 18:26, Edward Jaffe wrote:

On 7/18/2011 12:55 PM, Shmuel Metz (Seymour J.) wrote:
Are you saying that the processor starts fetching instructions for 
the branch prior to executing it?


Absolutely! There is a multi-stage pipeline that allows the processor 
to get ahead of the current instruction's execution to fetch and 
decode instructions, resolve addresses, fetch operands, etc. in 
advance of the actual instruction execution. Branch prediction (with a 
history table or target buffer) is used to help ensure the pipeline 
keeps flowing even when branches are encountered. IIRC, some models 
even fetch down more than one branch target path to minimize the 
performance hit if the first prediction is wrong.




Sounds almost thiotimoline like to me. (Sorry, I'm almost in vacation mode)/
/

--
Mark Jacobs
Time Customer Service
Tampa, FL


Some people are electrifying, they light up
a room when they leave.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-18 Thread Edward Jaffe

On 7/18/2011 12:55 PM, Shmuel Metz (Seymour J.) wrote:
Are you saying that the processor starts fetching instructions for the branch 
prior to executing it?


Absolutely! There is a multi-stage pipeline that allows the processor to get 
ahead of the current instruction's execution to fetch and decode instructions, 
resolve addresses, fetch operands, etc. in advance of the actual instruction 
execution. Branch prediction (with a history table or target buffer) is used to 
help ensure the pipeline keeps flowing even when branches are encountered. IIRC, 
some models even fetch down more than one branch target path to minimize the 
performance hit if the first prediction is wrong.


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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-18 Thread Shmuel Metz (Seymour J.)
In <4e248256.90...@phoenixsoftware.com>, on 07/18/2011
   at 11:58 AM, Edward Jaffe  said:

>If the target AMODE guessed by the hardware is wrong, then it will
>have to start over again fetching and interpreting the instructions
>in the correct AMODE.

Are you saying that the processor starts fetching instructions for the
branch prior to executing it? I would expect the processor to only be
reading ahead from the locations following the branch until it was
ready to perform the branch. Of course, there are techniques to
execute a branch out of sequence, but I see no reason that the AMODE
wouldn't be handled as part of that.

Could one of the IBM processor people comment?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-18 Thread Ed Finnell
IIRC Ray Wicks said they achieve about 91% hit ratio from HSB, but
that was for XA don't know what the numbers are for 64 bit.
 
 
In a message dated 7/18/2011 2:17:31 P.M. Central Daylight Time,  
edja...@phoenixsoftware.com writes:

If the  target AMODE guessed by the hardware is wrong, then it will have to 
start  
over again fetching and interpreting the instructions in the correct  AMODE.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-18 Thread Edward Jaffe

On 7/17/2011 11:11 AM, Shmuel Metz (Seymour J.) wrote:

Why would a branch with AMODE switching require more pipeline flushing
than a branch without?


If the target AMODE guessed by the hardware is wrong, then it will have to start 
over again fetching and interpreting the instructions in the correct AMODE.


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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-18 Thread Shmuel Metz (Seymour J.)
In <4e20f40d.2050...@phoenixsoftware.com>, on 07/15/2011
   at 07:14 PM, Edward Jaffe  said:

>There is no way the processor can know in advance which bits will be
>on in a  branch target register, so its seems likely that the
>pipeline must be flushed  when 'surprise' AMODE switching occurs for
>pointer-defined linkage. 

Why would a branch with AMODE switching require more pipeline flushing
than a branch without?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-15 Thread Greg Price
Steve Comstock wrote:
> 
> The real issue is what LE uses to switch AMODE when the
> setting is AMODE31(OFF); it may be more than just a BASSM
> or SAMxx. I don't really know, but I somehow expect overhead
> and complexity in that scenario (COBOL interacting with non-LE
> Assembler, as specified in the OP)

I've seen cases where shipped LE apps that work most places
encounter program checks (once it was an infinite loop induced
by a storage overlay) in the LE thunking layer at a couple of sites.
Overridding local LE settings to ALL31(ON) seems to circumvent
the problem.

Cheers,
Greg

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-15 Thread Ted MacNEIL
>The real issue is what LE uses to switch AMODE when the
setting is AMODE31(OFF); it may be more than just a BASSM
or SAMxx. I don't really know, but I somehow expect overhead
and complexity in that scenario (COBOL interacting with non-LE
Assembler, as specified in the OP)

Come on now!
There is little to no measurable over overhead in these scenarios!



-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-15 Thread Steve Comstock

On 7/15/2011 8:14 PM, Edward Jaffe wrote:

On 7/14/2011 12:55 PM, Tom Marchant wrote:

On Thu, 14 Jul 2011 08:40:37 -0600, Steve Comstock wrote:


yes, there is some penalty
for AMODE switching.

What penalty is that, Steve? Do BASSM and BSM run significantly
slower than BASR/BALR and BR?


There is no way the processor can know in advance which bits will be on in a
branch target register, so its seems likely that the pipeline must be flushed
when 'surprise' AMODE switching occurs for pointer-defined linkage. However, if
the BASSM/BSM is executed frequently enough, it's also possible the branch
history/prediction logic in the processor can guess the right target AMODE a
significant percentage of the time to minimize such 'surprises'.

I would not expect this to be an issue at all with the SAMxx instructions.



The real issue is what LE uses to switch AMODE when the
setting is AMODE31(OFF); it may be more than just a BASSM
or SAMxx. I don't really know, but I somehow expect overhead
and complexity in that scenario (COBOL interacting with non-LE
Assembler, as specified in the OP)


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* Special promotion: 15% off on all DB2 training classes
scheduled by September 1, taught by year end 2011

* Check out our entire DB2 curriculum at:
http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-15 Thread Edward Jaffe

On 7/14/2011 12:55 PM, Tom Marchant wrote:

On Thu, 14 Jul 2011 08:40:37 -0600, Steve Comstock wrote:


yes, there is some penalty
for AMODE switching.

What penalty is that, Steve?  Do BASSM and BSM run significantly
slower than BASR/BALR and BR?


There is no way the processor can know in advance which bits will be on in a 
branch target register, so its seems likely that the pipeline must be flushed 
when 'surprise' AMODE switching occurs for pointer-defined linkage. However, if 
the BASSM/BSM is executed frequently enough, it's also possible the branch 
history/prediction logic in the processor can guess the right target AMODE a 
significant percentage of the time to minimize such 'surprises'.


I would not expect this to be an issue at all with the SAMxx instructions.

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Tom Marchant
On Thu, 14 Jul 2011 08:40:37 -0600, Steve Comstock wrote:

>yes, there is some penalty
>for AMODE switching.

What penalty is that, Steve?  Do BASSM and BSM run significantly 
slower than BASR/BALR and BR?

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Chase, John
One need not specify compiler option DYNAM in order to use dynamic COBOL
calls, which indeed work "just fine and dandy" in CICS.  Now, that said:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IGY3CG40/2.23

Last note on the page.

Also:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DFHP3C00/1.3.
1

Scroll down to "Compiler Options".

-jc-

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Farley, Peter x23353
> 
> Actually not true.  I have done it frequently when it made sense to do
so.  COBOL dynamic CALL in CICS
> has been supported for quite some time now.  The trick is to limit the
use to subprograms that don't
> need to use CICS calls, but even that is possible if you pass the EIB
along.
> 
> Of course, you do NOT want a QSAM I/O module being invoked under CICS,
that would be quite bad.  Nor
> do you want any subprogram that invokes any z/OS services directly to
be called, but that has always
> been true.
> 
> Nonetheless, dynamic COBOL calls are supported and useful in CICS.
What you lose is debugging
> information from CICS in the event of any abend or failure in the
subprogram, because CICS thinks that
> the calling program is the one in control and not the dynamically
called subprogram, since CICS LINK
> was not used to invoke it.
> 
> HTH
> 
> Peter
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> > Behalf Of Chase, John
> > Sent: Thursday, July 14, 2011 10:39 AM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> >
> > How would TCB switching occur at all?  Are these programs running in
> > CICS?  If so, you cannot use the DYNAM compiler option for COBOL.
> --
> 
> This message and any attachments are intended only for the use of the
addressee and may contain
> information that is privileged and confidential. If the reader of the
message is not the intended
> recipient or an authorized representative of the intended recipient,
you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you
have received this communication in
> error, please notify us immediately by e-mail and delete the message
and any attachments from your
> system.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Farley, Peter x23353
Actually not true.  I have done it frequently when it made sense to do so.  
COBOL dynamic CALL in CICS has been supported for quite some time now.  The 
trick is to limit the use to subprograms that don't need to use CICS calls, but 
even that is possible if you pass the EIB along.

Of course, you do NOT want a QSAM I/O module being invoked under CICS, that 
would be quite bad.  Nor do you want any subprogram that invokes any z/OS 
services directly to be called, but that has always been true.

Nonetheless, dynamic COBOL calls are supported and useful in CICS.  What you 
lose is debugging information from CICS in the event of any abend or failure in 
the subprogram, because CICS thinks that the calling program is the one in 
control and not the dynamically called subprogram, since CICS LINK was not used 
to invoke it.

HTH

Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Chase, John
> Sent: Thursday, July 14, 2011 10:39 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> 
> How would TCB switching occur at all?  Are these programs running in
> CICS?  If so, you cannot use the DYNAM compiler option for COBOL.
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Victor Gil
Sure!

One more thing - the LE stack must say BELOW for the parameter list [pointed by 
R1] to be accessible by the AMODE24 routine 

E.g. STACK(131072,131072,BELOW,KEEP,524288,131072)

On Thu, 14 Jul 2011 11:28:07 -0400, Barkow, Eileen  
wrote:

>Maybe ALL31(OFF) would be the simplest thing to use -
>Although the programmers may not be looking for the simplest solution.
>
>Thanks for this info Victor
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
>Victor Gil
>Sent: Thursday, July 14, 2011 11:18 AM
>To: IBM-MAIN@bama.ua.edu
>Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
>
>Just wanted to add a bit to Peter's advice -
>
>The LE option ALL31(OFF) instructs [or at least used to] LE to perform AMODE 
>switching on every dynamic call, AND also to allocate the COBOL EXTERNAL data 
>in storage BELOW the line.
>
>So, if you define something like this
>
>001100 01 BELOWEXTERNAL.
>00120005 AMODE24-PARM-1PIC X(08).
>00120005 AMODE24-PARM-2PIC X(44).
>  ...
>
>the called AMODE24 program should have no problems accessing these PARMs.
>
>HTH,
>-Victor-
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Barkow, Eileen
Maybe ALL31(OFF) would be the simplest thing to use -
Although the programmers may not be looking for the simplest solution.

Thanks for this info Victor

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Victor Gil
Sent: Thursday, July 14, 2011 11:18 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

Just wanted to add a bit to Peter's advice -

The LE option ALL31(OFF) instructs [or at least used to] LE to perform AMODE 
switching on every dynamic call, AND also to allocate the COBOL EXTERNAL data 
in storage BELOW the line.

So, if you define something like this 

001100 01 BELOWEXTERNAL.  
00120005 AMODE24-PARM-1PIC X(08).
00120005 AMODE24-PARM-2PIC X(44).
  ...  
 
the called AMODE24 program should have no problems accessing these PARMs.

HTH,
-Victor-  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Victor Gil
Just wanted to add a bit to Peter's advice -

The LE option ALL31(OFF) instructs [or at least used to] LE to perform AMODE 
switching on every dynamic call, AND also to allocate the COBOL EXTERNAL data 
in storage BELOW the line.

So, if you define something like this 

001100 01 BELOWEXTERNAL.  
00120005 AMODE24-PARM-1PIC X(08).
00120005 AMODE24-PARM-2PIC X(44).
  ...  
 
the called AMODE24 program should have no problems accessing these PARMs.

HTH,
-Victor-  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Schumacher, Otto
If the assembler program is not LE compliant and Reentrant and Reuseable there 
will be a performance issue when the module is called Dynamically. 

Regards
Otto Schumacher
 
HP Enterprise Services
Infrastructure Specialist
Ahold Account
CICS & Capacity Technical Support
P.O. Box 6462
2000 Wade Hampton Blvd.
LC1-302
Greenville,  South Carolina, 29606
Cell: 864 569--5338
Tel: 864 987-1417
Fax: 864 987-4500
E-mail: otto.schumac...@hp.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Barkow, Eileen
Sent: Thursday, July 14, 2011 11:05 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

These are batch programs that they are working on (I hope, since they are 
invoking MVS IO routines directly).
However, this group of programmers are also heavy CICS users - I did not ask if 
the programs were CICS or not.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Chase, John
Sent: Thursday, July 14, 2011 10:39 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

How would TCB switching occur at all?  Are these programs running in
CICS?  If so, you cannot use the DYNAM compiler option for COBOL.

-jc-

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Barkow, Eileen
> Sent: Thursday, July 14, 2011 9:30 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> 
> The programmer has a question about possible TCB switching:
> 
> Option 2 seems better. DATA(31) should allow most of the callers
storage to reside above the line, and
> switch to below the line processing only when calling the assembler
routine. Would excessive TCB
> switching result if the assembler program is invoked repeatedly for
file i/o, or does that not come
> into play?
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Farley, Peter x23353
> Sent: Wednesday, July 13, 2011 4:53 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> 
> Option #1 is simpler, that is true.  I also forgot to say that the
COBOL compiler option DYNAM will
> also be required so that if the 24-bit assembler program is called
using CALL literal (like CALL
> 'MYASMIO'), then it will be loaded at run time instead of linked in
statically.  I assume from your
> original post that this must be your case, otherwise the programmers
would not be worrying about
> including the 24-bit program as part of the link step.
> 
> However, Option #2 does have the advantage of allowing the
WORKING-STORAGE of the COBOL programs to
> grow much larger in 31-bit storage without worrying about using up all
available 24-bit storage.  If
> growth of internal tables or data in the COBOL programs over time is a
possible future maintenance
> headache for using DATA(24), it might be better (though more work) to
bite the bullet and take option
> #2 now instead of later.
> 
> OTOH getting that 24-bit assembler I/O program correctly converted to
31-bit is the better long-term
> option over all, and DATA(24) plus DYNAM gives you time to do that as
a priority.  When that is done
> you can switch the COBOL compiles to DATA(31) and you're done.
> 
> Good luck, and feel free to ask more questions if you need to.
> 
> HTH
> 
> Peter
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> > Behalf Of Barkow, Eileen
> > Sent: Wednesday, July 13, 2011 4:06 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> >
> > Thank you Peter.
> > I missed your post yesterday morning as well as some others.
> > I am beginning to think that there was delay in the email yesterday
> > morning and the msgs were delivered later in the
> > Day so I did not notice the earlier ones.
> >
> > Option #1 sounds simpler than 2 since it does not require any code
> > changes.
> --
> 
> This message and any attachments are intended only for the use of the
addressee and may contain
> information that is privileged and confidential. If the reader of the
message is not the intended
> recipient or an authorized representative of the intended recipient,
you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you
have received this communication in
> error, please notify us immediately by e-mail and delete the message
and any attachments from your
> system.
> 
> 
> ---

Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Charles Mills
Getting the old QSAM assembler code to run in AMODE 31 is fairly trivial
(probably -- I have not seen the code). Best case no code changes whatsoever
are necessary.

It is RMODE ANY that takes some effort.

So you should be able to make AMODE switching a non-event.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Barkow, Eileen
Sent: Thursday, July 14, 2011 10:30 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

The programmer has a question about possible TCB switching:

Option 2 seems better. DATA(31) should allow most of the callers storage to
reside above the line, and switch to below the line processing only when
calling the assembler routine. Would excessive TCB switching result if the
assembler program is invoked repeatedly for file i/o, or does that not come
into play?
HTH

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Barkow, Eileen
These are batch programs that they are working on (I hope, since they are 
invoking MVS IO routines directly).
However, this group of programmers are also heavy CICS users - I did not ask if 
the programs were CICS or not.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Chase, John
Sent: Thursday, July 14, 2011 10:39 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

How would TCB switching occur at all?  Are these programs running in
CICS?  If so, you cannot use the DYNAM compiler option for COBOL.

-jc-

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Barkow, Eileen
> Sent: Thursday, July 14, 2011 9:30 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> 
> The programmer has a question about possible TCB switching:
> 
> Option 2 seems better. DATA(31) should allow most of the callers
storage to reside above the line, and
> switch to below the line processing only when calling the assembler
routine. Would excessive TCB
> switching result if the assembler program is invoked repeatedly for
file i/o, or does that not come
> into play?
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Farley, Peter x23353
> Sent: Wednesday, July 13, 2011 4:53 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> 
> Option #1 is simpler, that is true.  I also forgot to say that the
COBOL compiler option DYNAM will
> also be required so that if the 24-bit assembler program is called
using CALL literal (like CALL
> 'MYASMIO'), then it will be loaded at run time instead of linked in
statically.  I assume from your
> original post that this must be your case, otherwise the programmers
would not be worrying about
> including the 24-bit program as part of the link step.
> 
> However, Option #2 does have the advantage of allowing the
WORKING-STORAGE of the COBOL programs to
> grow much larger in 31-bit storage without worrying about using up all
available 24-bit storage.  If
> growth of internal tables or data in the COBOL programs over time is a
possible future maintenance
> headache for using DATA(24), it might be better (though more work) to
bite the bullet and take option
> #2 now instead of later.
> 
> OTOH getting that 24-bit assembler I/O program correctly converted to
31-bit is the better long-term
> option over all, and DATA(24) plus DYNAM gives you time to do that as
a priority.  When that is done
> you can switch the COBOL compiles to DATA(31) and you're done.
> 
> Good luck, and feel free to ask more questions if you need to.
> 
> HTH
> 
> Peter
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> > Behalf Of Barkow, Eileen
> > Sent: Wednesday, July 13, 2011 4:06 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> >
> > Thank you Peter.
> > I missed your post yesterday morning as well as some others.
> > I am beginning to think that there was delay in the email yesterday
> > morning and the msgs were delivered later in the
> > Day so I did not notice the earlier ones.
> >
> > Option #1 sounds simpler than 2 since it does not require any code
> > changes.
> --
> 
> This message and any attachments are intended only for the use of the
addressee and may contain
> information that is privileged and confidential. If the reader of the
message is not the intended
> recipient or an authorized representative of the intended recipient,
you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you
have received this communication in
> error, please notify us immediately by e-mail and delete the message
and any attachments from your
> system.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the

Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Chase, John
How would TCB switching occur at all?  Are these programs running in
CICS?  If so, you cannot use the DYNAM compiler option for COBOL.

-jc-

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Barkow, Eileen
> Sent: Thursday, July 14, 2011 9:30 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> 
> The programmer has a question about possible TCB switching:
> 
> Option 2 seems better. DATA(31) should allow most of the callers
storage to reside above the line, and
> switch to below the line processing only when calling the assembler
routine. Would excessive TCB
> switching result if the assembler program is invoked repeatedly for
file i/o, or does that not come
> into play?
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Farley, Peter x23353
> Sent: Wednesday, July 13, 2011 4:53 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> 
> Option #1 is simpler, that is true.  I also forgot to say that the
COBOL compiler option DYNAM will
> also be required so that if the 24-bit assembler program is called
using CALL literal (like CALL
> 'MYASMIO'), then it will be loaded at run time instead of linked in
statically.  I assume from your
> original post that this must be your case, otherwise the programmers
would not be worrying about
> including the 24-bit program as part of the link step.
> 
> However, Option #2 does have the advantage of allowing the
WORKING-STORAGE of the COBOL programs to
> grow much larger in 31-bit storage without worrying about using up all
available 24-bit storage.  If
> growth of internal tables or data in the COBOL programs over time is a
possible future maintenance
> headache for using DATA(24), it might be better (though more work) to
bite the bullet and take option
> #2 now instead of later.
> 
> OTOH getting that 24-bit assembler I/O program correctly converted to
31-bit is the better long-term
> option over all, and DATA(24) plus DYNAM gives you time to do that as
a priority.  When that is done
> you can switch the COBOL compiles to DATA(31) and you're done.
> 
> Good luck, and feel free to ask more questions if you need to.
> 
> HTH
> 
> Peter
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> > Behalf Of Barkow, Eileen
> > Sent: Wednesday, July 13, 2011 4:06 PM
> > To: IBM-MAIN@bama.ua.edu
> > Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> >
> > Thank you Peter.
> > I missed your post yesterday morning as well as some others.
> > I am beginning to think that there was delay in the email yesterday
> > morning and the msgs were delivered later in the
> > Day so I did not notice the earlier ones.
> >
> > Option #1 sounds simpler than 2 since it does not require any code
> > changes.
> --
> 
> This message and any attachments are intended only for the use of the
addressee and may contain
> information that is privileged and confidential. If the reader of the
message is not the intended
> recipient or an authorized representative of the intended recipient,
you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you
have received this communication in
> error, please notify us immediately by e-mail and delete the message
and any attachments from your
> system.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Barkow, Eileen
The programmers are still considering all of the options.
I told them to join IBM-MAIN themselves and ask the questions - I am just a 
go-between.

But thanks for the info Steve. I sent the users the info about your papers and 
will pass this info about
Amode switching onto them as well.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Steve Comstock
Sent: Thursday, July 14, 2011 10:41 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

On 7/14/2011 8:30 AM, Barkow, Eileen wrote:
> The programmer has a question about possible TCB switching:
>
> Option 2 seems better. DATA(31) should allow most of the
> callers storage to reside above the line, and switch to
> below the line processing only when calling the assembler
> routine. Would excessive TCB switching result if the assembler
> program is invoked repeatedly for file i/o, or does that not come into play?

Your programmer is mis-speaking. I don't know what "TCB switching" is;
they probably mean AMODE switching. And, yes, there is some penalty
for AMODE switching.

I thought you mentioned the programmer was going to re-write the
Assembler code, in which case it can be setup to be AMODE 31 and
stay that way and there is no such problem.


>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of Farley, Peter x23353
> Sent: Wednesday, July 13, 2011 4:53 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
>
> Option #1 is simpler, that is true.  I also forgot to say that the COBOL 
> compiler option DYNAM will also be required so that if the 24-bit assembler 
> program is called using CALL literal (like CALL 'MYASMIO'), then it will be 
> loaded at run time instead of linked in statically.  I assume from your 
> original post that this must be your case, otherwise the programmers would 
> not be worrying about including the 24-bit program as part of the link step.
>
> However, Option #2 does have the advantage of allowing the WORKING-STORAGE of 
> the COBOL programs to grow much larger in 31-bit storage without worrying 
> about using up all available 24-bit storage.  If growth of internal tables or 
> data in the COBOL programs over time is a possible future maintenance 
> headache for using DATA(24), it might be better (though more work) to bite 
> the bullet and take option #2 now instead of later.
>
> OTOH getting that 24-bit assembler I/O program correctly converted to 31-bit 
> is the better long-term option over all, and DATA(24) plus DYNAM gives you 
> time to do that as a priority.  When that is done you can switch the COBOL 
> compiles to DATA(31) and you're done.
>
> Good luck, and feel free to ask more questions if you need to.
>
> HTH
>
> Peter
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
>> Behalf Of Barkow, Eileen
>> Sent: Wednesday, July 13, 2011 4:06 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
>>
>> Thank you Peter.
>> I missed your post yesterday morning as well as some others.
>> I am beginning to think that there was delay in the email yesterday
>> morning and the msgs were delivered later in the
>> Day so I did not notice the earlier ones.
>>
>> Option #1 sounds simpler than 2 since it does not require any code
>> changes.
> --
>
> This message and any attachments are intended only for the use of the 
> addressee and may contain information that is privileged and confidential. If 
> the reader of the message is not the intended recipient or an authorized 
> representative of the intended recipient, you are hereby notified that any 
> dissemination of this communication is strictly prohibited. If you have 
> received this communication in error, please notify us immediately by e-mail 
> and delete the message and any attachments from your system.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>


-- 

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

*

Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Steve Comstock

On 7/14/2011 8:30 AM, Barkow, Eileen wrote:

The programmer has a question about possible TCB switching:

Option 2 seems better. DATA(31) should allow most of the
callers storage to reside above the line, and switch to
below the line processing only when calling the assembler
routine. Would excessive TCB switching result if the assembler
program is invoked repeatedly for file i/o, or does that not come into play?


Your programmer is mis-speaking. I don't know what "TCB switching" is;
they probably mean AMODE switching. And, yes, there is some penalty
for AMODE switching.

I thought you mentioned the programmer was going to re-write the
Assembler code, in which case it can be setup to be AMODE 31 and
stay that way and there is no such problem.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Farley, Peter x23353
Sent: Wednesday, July 13, 2011 4:53 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

Option #1 is simpler, that is true.  I also forgot to say that the COBOL 
compiler option DYNAM will also be required so that if the 24-bit assembler 
program is called using CALL literal (like CALL 'MYASMIO'), then it will be 
loaded at run time instead of linked in statically.  I assume from your 
original post that this must be your case, otherwise the programmers would not 
be worrying about including the 24-bit program as part of the link step.

However, Option #2 does have the advantage of allowing the WORKING-STORAGE of 
the COBOL programs to grow much larger in 31-bit storage without worrying about 
using up all available 24-bit storage.  If growth of internal tables or data in 
the COBOL programs over time is a possible future maintenance headache for 
using DATA(24), it might be better (though more work) to bite the bullet and 
take option #2 now instead of later.

OTOH getting that 24-bit assembler I/O program correctly converted to 31-bit is 
the better long-term option over all, and DATA(24) plus DYNAM gives you time to 
do that as a priority.  When that is done you can switch the COBOL compiles to 
DATA(31) and you're done.

Good luck, and feel free to ask more questions if you need to.

HTH

Peter


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Barkow, Eileen
Sent: Wednesday, July 13, 2011 4:06 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

Thank you Peter.
I missed your post yesterday morning as well as some others.
I am beginning to think that there was delay in the email yesterday
morning and the msgs were delivered later in the
Day so I did not notice the earlier ones.

Option #1 sounds simpler than 2 since it does not require any code
changes.

--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html




--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* Special promotion: 15% off on all DB2 training classes
scheduled by September 1, taught by year end 2011

* Check out our entire DB2 curriculum at:
http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Barkow, Eileen
The programmer has a question about possible TCB switching:

Option 2 seems better. DATA(31) should allow most of the callers storage to 
reside above the line, and switch to below the line processing only when 
calling the assembler routine. Would excessive TCB switching result if the 
assembler program is invoked repeatedly for file i/o, or does that not come 
into play?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Farley, Peter x23353
Sent: Wednesday, July 13, 2011 4:53 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

Option #1 is simpler, that is true.  I also forgot to say that the COBOL 
compiler option DYNAM will also be required so that if the 24-bit assembler 
program is called using CALL literal (like CALL 'MYASMIO'), then it will be 
loaded at run time instead of linked in statically.  I assume from your 
original post that this must be your case, otherwise the programmers would not 
be worrying about including the 24-bit program as part of the link step.

However, Option #2 does have the advantage of allowing the WORKING-STORAGE of 
the COBOL programs to grow much larger in 31-bit storage without worrying about 
using up all available 24-bit storage.  If growth of internal tables or data in 
the COBOL programs over time is a possible future maintenance headache for 
using DATA(24), it might be better (though more work) to bite the bullet and 
take option #2 now instead of later.

OTOH getting that 24-bit assembler I/O program correctly converted to 31-bit is 
the better long-term option over all, and DATA(24) plus DYNAM gives you time to 
do that as a priority.  When that is done you can switch the COBOL compiles to 
DATA(31) and you're done.

Good luck, and feel free to ask more questions if you need to.

HTH

Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Barkow, Eileen
> Sent: Wednesday, July 13, 2011 4:06 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> 
> Thank you Peter.
> I missed your post yesterday morning as well as some others.
> I am beginning to think that there was delay in the email yesterday
> morning and the msgs were delivered later in the
> Day so I did not notice the earlier ones.
> 
> Option #1 sounds simpler than 2 since it does not require any code
> changes.
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-14 Thread Barkow, Eileen
Thanks again Peter.
I passed this info along to the programmers as well - I think that they want to 
convert the assembler program to 31 bit.

Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Farley, Peter x23353
Sent: Wednesday, July 13, 2011 4:53 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

Option #1 is simpler, that is true.  I also forgot to say that the COBOL 
compiler option DYNAM will also be required so that if the 24-bit assembler 
program is called using CALL literal (like CALL 'MYASMIO'), then it will be 
loaded at run time instead of linked in statically.  I assume from your 
original post that this must be your case, otherwise the programmers would not 
be worrying about including the 24-bit program as part of the link step.

However, Option #2 does have the advantage of allowing the WORKING-STORAGE of 
the COBOL programs to grow much larger in 31-bit storage without worrying about 
using up all available 24-bit storage.  If growth of internal tables or data in 
the COBOL programs over time is a possible future maintenance headache for 
using DATA(24), it might be better (though more work) to bite the bullet and 
take option #2 now instead of later.

OTOH getting that 24-bit assembler I/O program correctly converted to 31-bit is 
the better long-term option over all, and DATA(24) plus DYNAM gives you time to 
do that as a priority.  When that is done you can switch the COBOL compiles to 
DATA(31) and you're done.

Good luck, and feel free to ask more questions if you need to.

HTH

Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Barkow, Eileen
> Sent: Wednesday, July 13, 2011 4:06 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> 
> Thank you Peter.
> I missed your post yesterday morning as well as some others.
> I am beginning to think that there was delay in the email yesterday
> morning and the msgs were delivered later in the
> Day so I did not notice the earlier ones.
> 
> Option #1 sounds simpler than 2 since it does not require any code
> changes.
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-13 Thread Farley, Peter x23353
Option #1 is simpler, that is true.  I also forgot to say that the COBOL 
compiler option DYNAM will also be required so that if the 24-bit assembler 
program is called using CALL literal (like CALL 'MYASMIO'), then it will be 
loaded at run time instead of linked in statically.  I assume from your 
original post that this must be your case, otherwise the programmers would not 
be worrying about including the 24-bit program as part of the link step.

However, Option #2 does have the advantage of allowing the WORKING-STORAGE of 
the COBOL programs to grow much larger in 31-bit storage without worrying about 
using up all available 24-bit storage.  If growth of internal tables or data in 
the COBOL programs over time is a possible future maintenance headache for 
using DATA(24), it might be better (though more work) to bite the bullet and 
take option #2 now instead of later.

OTOH getting that 24-bit assembler I/O program correctly converted to 31-bit is 
the better long-term option over all, and DATA(24) plus DYNAM gives you time to 
do that as a priority.  When that is done you can switch the COBOL compiles to 
DATA(31) and you're done.

Good luck, and feel free to ask more questions if you need to.

HTH

Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Barkow, Eileen
> Sent: Wednesday, July 13, 2011 4:06 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
> 
> Thank you Peter.
> I missed your post yesterday morning as well as some others.
> I am beginning to think that there was delay in the email yesterday
> morning and the msgs were delivered later in the
> Day so I did not notice the earlier ones.
> 
> Option #1 sounds simpler than 2 since it does not require any code
> changes.
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-13 Thread Barkow, Eileen
Thank you Peter.
I missed your post yesterday morning as well as some others.
I am beginning to think that there was delay in the email yesterday morning and 
the msgs were delivered later in the
Day so I did not notice the earlier ones.

Option #1 sounds simpler than 2 since it does not require any code changes.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Farley, Peter x23353
Sent: Tuesday, July 12, 2011 11:32 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

Option #1: Use COBOL dynamic CALL (CALL variable-name-containing-module-name) 
to invoke the assembler modules and compile with DATA(24) so that the data 
areas in WORKING-STORAGE are below the line.  Link COBOL as RMODE=ANY and 
AMODE=31.

Option #2: Also uses dynamic COBOL call but compiled with DATA(31).  Use LE 
callable storage subroutines (CEEGTST, CEEFRST) to obtain below-the-line 
storage for data areas to be passed to the assembler subroutines.  Define the 
24-bit data areas in the LINKAGE section, not WORKING-STORAGWE, and use SET 
ADDRESS OF 24-bit-data-area TO pointer-returned-by-LE to address those data 
areas.  Move data from 31-bit WORKING-STORAGE to the LINKAGE-defined 24-bit 
areas to pass to the subroutines.

HTH

Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Barkow, Eileen
> Sent: Tuesday, July 12, 2011 11:06 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: running Assembler I/O macro code as AMODE 31, RMODE ANY
> 
> We have some old Cobol programs that are being upgraded to Enterprise
> Cobol and the users would like to be able to link them as AMODE 31 RMODE
> ANY. The problem is that some of these programs call assembler modules to
> do the i/o via QSAM and VSAM macros (TESTCB, SHOWCB, GET, PUT, PUTX, etc)
> and the only way these can work is by linking everything as AMODE 24,
> RMODE BELOW.
> 
> Is there any way (like by using LE enabled Assembler), that the assembler
> macro code can run AMODE 31, RMODE ANY? I know that one way is to reset
> the mode dynamically via BSM and other mode setting instructions so that
> the data areas can be moved to 24 bit areas before the macros are issued
> and then moving them back to AMODE 31 areas to be passed back to the Cobol
> programs. But is there a simpler way to do this?
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-13 Thread Barkow, Eileen
Thank you Otto -

I just saw your post as well as Steve's.
I missed a lot of stuff yesterday morning.

The DATA(24) option sounds like a simple thing to use and does not require any 
code changes.
I will pass this info along to the programmers.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Schumacher, Otto
Sent: Tuesday, July 12, 2011 11:31 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

To fix this problem of allowing all storage to be above the line the Assembler 
I/O subroutines will need to be rewritten. You can have the Cobol program 
compile specifying the compiler option DATA(24) this will indicate to the COBOL 
compile to obtain working storage below the line. This action will allow you to 
call the assembler module that is Amode(24). The Cobol module will then link as 
a Amode 31 Rmode any program.  This compiler option change will allow the 
program code to move above the line but will leave the COBOL programs working 
storage below the line.   

Regards
Otto Schumacher
 
HP Enterprise Services
Infrastructure Specialist
Ahold Account
CICS & Capacity Technical Support
P.O. Box 6462
2000 Wade Hampton Blvd.
LC1-302
Greenville,  South Carolina, 29606
Cell: 864 569--5338
Tel: 864 987-1417
Fax: 864 987-4500
E-mail: otto.schumac...@hp.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Barkow, Eileen
Sent: Tuesday, July 12, 2011 11:06 AM
To: IBM-MAIN@bama.ua.edu
Subject: running Assembler I/O macro code as AMODE 31, RMODE ANY

We have some old Cobol programs that are being upgraded to Enterprise Cobol and
the users would like to be able to link them as AMODE 31 RMODE ANY.
The problem is that some of these programs call assembler modules to do the i/o 
via
QSAM and VSAM macros (TESTCB, SHOWCB, GET, PUT, PUTX, etc) and the only way 
these can work is
by linking everything as AMODE 24, RMODE BELOW.

Is there any way (like by using LE enabled Assembler), that the assembler macro 
code can run
AMODE 31, RMODE ANY? I know that one way is to reset the mode dynamically via 
BSM and other mode setting
instructions so that the data areas can be moved to 24 bit areas before the 
macros are issued and then moving
them back to AMODE 31 areas to be passed back to the Cobol programs.
But is there a simpler way to do this?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-13 Thread Barkow, Eileen
Thanks a lot Steve. I just saw the note that you sent yesterday - sorry I 
missed it.
I will pass your info along to the programmers.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Steve Comstock
Sent: Wednesday, July 13, 2011 3:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

On 7/13/2011 1:21 PM, Barkow, Eileen wrote:
> Steve,
>
> I am sorry but I did not see your post with the 3 papers mentioned.
> When was it sent? I hope I did not delete it - I get copies of alot of error 
> msg email that I send out to users and am
> constantly deleting them so I sometimes delete things by mistake.

I wondered. It was sent yesterday at 9:26 am;

   extracting:

VSAM can work AMODE 31 just fine.

For QSAM, there are a number of approaches that allow you
to code file processing in AMODE 31 without switching back
and forth using BSM and the like.

Visit

   http://www.trainersfriend.com/General_content/Book_site.htm

check out these papers:

* Applications Assembler Programming for z

* Writing Reentrant Programs (In Assembler)

* I/O and AMODE 31

they're all free and have some tidbits you might find helpful.



>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of Steve Comstock
> Sent: Wednesday, July 13, 2011 2:56 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
>
> On 7/13/2011 12:32 PM, Barkow, Eileen wrote:
>> I passed all the info I got from this list onto the programmers and they can 
>> decide what to do.
>>
>> John Gilmore sent the info about using RMODE(SPLIT) and Charles Mills sent a 
>> very comprehensive document (previously presented to the list) that he wrote 
>> about
>>how to convert assembler code doing such i/o's to 31 bit rmode(any).
>>
>
> I was curious if you saw my post with the three papers mentioned.
>
>
>> Thanks to all who responded.
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
>> Of Steve Comstock
>> Sent: Wednesday, July 13, 2011 2:19 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
>>
>> On 7/13/2011 11:53 AM, Barkow, Eileen wrote:
>>> I meant that linking everything AMODE 24 was the 'only' way the users could 
>>> get it to work - that is why they
>>> were asking for other ways to do it.
>>
>> So how have you resolved the problem?
>>
>>
>>>
>>> -----Original Message-
>>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
>>> Of Shmuel Metz (Seymour J.)
>>> Sent: Wednesday, July 13, 2011 1:48 PM
>>> To: IBM-MAIN@bama.ua.edu
>>> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
>>>
>>> In
>>> ,
>>> on 07/12/2011
>>>   at 11:06 AM, "Barkow, Eileen"said:
>>>
>>>> We have some old Cobol programs that are being upgraded to Enterprise
>>>> Cobol and the users would like to be able to link them as AMODE 31
>>>> RMODE ANY. The problem is that some of these programs call assembler
>>>> modules to do the i/o via QSAM and VSAM macros (TESTCB, SHOWCB, GET,
>>>> PUT, PUTX, etc) and the only way these can work is by linking
>>>> everything as AMODE 24, RMODE BELOW.
>>>
>>> That is *a* way; it is *NOT* the only way.
>>>
>>
>>
>
>


-- 

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* Special promotion: 15% off on all DB2 training classes
 scheduled by September 1, taught by year end 2011

* Check out our entire DB2 curriculum at:
 http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-13 Thread Steve Comstock

On 7/13/2011 1:21 PM, Barkow, Eileen wrote:

Steve,

I am sorry but I did not see your post with the 3 papers mentioned.
When was it sent? I hope I did not delete it - I get copies of alot of error 
msg email that I send out to users and am
constantly deleting them so I sometimes delete things by mistake.


I wondered. It was sent yesterday at 9:26 am;

  extracting:

VSAM can work AMODE 31 just fine.

For QSAM, there are a number of approaches that allow you
to code file processing in AMODE 31 without switching back
and forth using BSM and the like.

Visit

  http://www.trainersfriend.com/General_content/Book_site.htm

check out these papers:

* Applications Assembler Programming for z

* Writing Reentrant Programs (In Assembler)

* I/O and AMODE 31

they're all free and have some tidbits you might find helpful.





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Steve Comstock
Sent: Wednesday, July 13, 2011 2:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

On 7/13/2011 12:32 PM, Barkow, Eileen wrote:

I passed all the info I got from this list onto the programmers and they can 
decide what to do.

John Gilmore sent the info about using RMODE(SPLIT) and Charles Mills sent a 
very comprehensive document (previously presented to the list) that he wrote 
about
   how to convert assembler code doing such i/o's to 31 bit rmode(any).



I was curious if you saw my post with the three papers mentioned.



Thanks to all who responded.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Steve Comstock
Sent: Wednesday, July 13, 2011 2:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

On 7/13/2011 11:53 AM, Barkow, Eileen wrote:

I meant that linking everything AMODE 24 was the 'only' way the users could get 
it to work - that is why they
were asking for other ways to do it.


So how have you resolved the problem?




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Wednesday, July 13, 2011 1:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

In
,
on 07/12/2011
  at 11:06 AM, "Barkow, Eileen"said:


We have some old Cobol programs that are being upgraded to Enterprise
Cobol and the users would like to be able to link them as AMODE 31
RMODE ANY. The problem is that some of these programs call assembler
modules to do the i/o via QSAM and VSAM macros (TESTCB, SHOWCB, GET,
PUT, PUTX, etc) and the only way these can work is by linking
everything as AMODE 24, RMODE BELOW.


That is *a* way; it is *NOT* the only way.










--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* Special promotion: 15% off on all DB2 training classes
scheduled by September 1, taught by year end 2011

* Check out our entire DB2 curriculum at:
http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-13 Thread Barkow, Eileen
Steve,

I am sorry but I did not see your post with the 3 papers mentioned.
When was it sent? I hope I did not delete it - I get copies of alot of error 
msg email that I send out to users and am
constantly deleting them so I sometimes delete things by mistake.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Steve Comstock
Sent: Wednesday, July 13, 2011 2:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

On 7/13/2011 12:32 PM, Barkow, Eileen wrote:
> I passed all the info I got from this list onto the programmers and they can 
> decide what to do.
>
> John Gilmore sent the info about using RMODE(SPLIT) and Charles Mills sent a 
> very comprehensive document (previously presented to the list) that he wrote 
> about
>   how to convert assembler code doing such i/o's to 31 bit rmode(any).
>

I was curious if you saw my post with the three papers mentioned.


> Thanks to all who responded.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of Steve Comstock
> Sent: Wednesday, July 13, 2011 2:19 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
>
> On 7/13/2011 11:53 AM, Barkow, Eileen wrote:
>> I meant that linking everything AMODE 24 was the 'only' way the users could 
>> get it to work - that is why they
>> were asking for other ways to do it.
>
> So how have you resolved the problem?
>
>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
>> Of Shmuel Metz (Seymour J.)
>> Sent: Wednesday, July 13, 2011 1:48 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
>>
>> In
>> ,
>> on 07/12/2011
>>  at 11:06 AM, "Barkow, Eileen"   said:
>>
>>> We have some old Cobol programs that are being upgraded to Enterprise
>>> Cobol and the users would like to be able to link them as AMODE 31
>>> RMODE ANY. The problem is that some of these programs call assembler
>>> modules to do the i/o via QSAM and VSAM macros (TESTCB, SHOWCB, GET,
>>> PUT, PUTX, etc) and the only way these can work is by linking
>>> everything as AMODE 24, RMODE BELOW.
>>
>> That is *a* way; it is *NOT* the only way.
>>
>
>


-- 

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* Special promotion: 15% off on all DB2 training classes
 scheduled by September 1, taught by year end 2011

* Check out our entire DB2 curriculum at:
 http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-13 Thread Steve Comstock

On 7/13/2011 12:32 PM, Barkow, Eileen wrote:

I passed all the info I got from this list onto the programmers and they can 
decide what to do.

John Gilmore sent the info about using RMODE(SPLIT) and Charles Mills sent a 
very comprehensive document (previously presented to the list) that he wrote 
about
  how to convert assembler code doing such i/o's to 31 bit rmode(any).



I was curious if you saw my post with the three papers mentioned.



Thanks to all who responded.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Steve Comstock
Sent: Wednesday, July 13, 2011 2:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

On 7/13/2011 11:53 AM, Barkow, Eileen wrote:

I meant that linking everything AMODE 24 was the 'only' way the users could get 
it to work - that is why they
were asking for other ways to do it.


So how have you resolved the problem?




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Wednesday, July 13, 2011 1:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

In
,
on 07/12/2011
 at 11:06 AM, "Barkow, Eileen"   said:


We have some old Cobol programs that are being upgraded to Enterprise
Cobol and the users would like to be able to link them as AMODE 31
RMODE ANY. The problem is that some of these programs call assembler
modules to do the i/o via QSAM and VSAM macros (TESTCB, SHOWCB, GET,
PUT, PUTX, etc) and the only way these can work is by linking
everything as AMODE 24, RMODE BELOW.


That is *a* way; it is *NOT* the only way.







--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* Special promotion: 15% off on all DB2 training classes
scheduled by September 1, taught by year end 2011

* Check out our entire DB2 curriculum at:
http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-13 Thread Barkow, Eileen
I passed all the info I got from this list onto the programmers and they can 
decide what to do.

John Gilmore sent the info about using RMODE(SPLIT) and Charles Mills sent a 
very comprehensive document (previously presented to the list) that he wrote 
about
 how to convert assembler code doing such i/o's to 31 bit rmode(any).

Thanks to all who responded.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Steve Comstock
Sent: Wednesday, July 13, 2011 2:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

On 7/13/2011 11:53 AM, Barkow, Eileen wrote:
> I meant that linking everything AMODE 24 was the 'only' way the users could 
> get it to work - that is why they
> were asking for other ways to do it.

So how have you resolved the problem?


>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of Shmuel Metz (Seymour J.)
> Sent: Wednesday, July 13, 2011 1:48 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
>
> In
> ,
> on 07/12/2011
> at 11:06 AM, "Barkow, Eileen"  said:
>
>> We have some old Cobol programs that are being upgraded to Enterprise
>> Cobol and the users would like to be able to link them as AMODE 31
>> RMODE ANY. The problem is that some of these programs call assembler
>> modules to do the i/o via QSAM and VSAM macros (TESTCB, SHOWCB, GET,
>> PUT, PUTX, etc) and the only way these can work is by linking
>> everything as AMODE 24, RMODE BELOW.
>
> That is *a* way; it is *NOT* the only way.
>


-- 

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* Special promotion: 15% off on all DB2 training classes
 scheduled by September 1, taught by year end 2011

* Check out our entire DB2 curriculum at:
 http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-13 Thread Steve Comstock

On 7/13/2011 11:53 AM, Barkow, Eileen wrote:

I meant that linking everything AMODE 24 was the 'only' way the users could get 
it to work - that is why they
were asking for other ways to do it.


So how have you resolved the problem?




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Wednesday, July 13, 2011 1:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

In
,
on 07/12/2011
at 11:06 AM, "Barkow, Eileen"  said:


We have some old Cobol programs that are being upgraded to Enterprise
Cobol and the users would like to be able to link them as AMODE 31
RMODE ANY. The problem is that some of these programs call assembler
modules to do the i/o via QSAM and VSAM macros (TESTCB, SHOWCB, GET,
PUT, PUTX, etc) and the only way these can work is by linking
everything as AMODE 24, RMODE BELOW.


That is *a* way; it is *NOT* the only way.




--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* Special promotion: 15% off on all DB2 training classes
scheduled by September 1, taught by year end 2011

* Check out our entire DB2 curriculum at:
http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-13 Thread Barkow, Eileen
I meant that linking everything AMODE 24 was the 'only' way the users could get 
it to work - that is why they
were asking for other ways to do it.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Wednesday, July 13, 2011 1:48 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

In
,
on 07/12/2011
   at 11:06 AM, "Barkow, Eileen"  said:

>We have some old Cobol programs that are being upgraded to Enterprise
>Cobol and the users would like to be able to link them as AMODE 31
>RMODE ANY. The problem is that some of these programs call assembler
>modules to do the i/o via QSAM and VSAM macros (TESTCB, SHOWCB, GET,
>PUT, PUTX, etc) and the only way these can work is by linking
>everything as AMODE 24, RMODE BELOW.

That is *a* way; it is *NOT* the only way.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-13 Thread Shmuel Metz (Seymour J.)
In
,
on 07/12/2011
   at 11:06 AM, "Barkow, Eileen"  said:

>We have some old Cobol programs that are being upgraded to Enterprise
>Cobol and the users would like to be able to link them as AMODE 31
>RMODE ANY. The problem is that some of these programs call assembler
>modules to do the i/o via QSAM and VSAM macros (TESTCB, SHOWCB, GET,
>PUT, PUTX, etc) and the only way these can work is by linking
>everything as AMODE 24, RMODE BELOW.

That is *a* way; it is *NOT* the only way.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-13 Thread Barkow, Eileen
As per this item, RMODE(SPLIT) cannot be used for COBOL.

https://www-304.ibm.com/support/docview.wss?uid=swg21253383



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
john gilmore
Sent: Tuesday, July 12, 2011 11:43 AM
To: IBM-MAIN@bama.ua.edu
Subject: running Assembler I/O macro code as AMODE 31, RMODE ANY



If you cannot dispense with your RYO I/O routines, use RMODE(SPLIT), which is 
discussed in the z/OS Program Management User's Guide.  I have used it in these 
situations many times.



John Gilmore Ashland, MA 01721-1817 USA

--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO

Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-12 Thread Charles Mills
I've got a paper I wrote on how to convert a QSAM or BSAM assembler module
to 31-bit. I offered it here some years ago and I still get requests. Let me
renew the offer at this time. Write me off-list.

It's not a magic solution. It is basically your "the data areas can be moved
to 24 bit areas before the macros are issued." It's basically a cookbook for
doing that.

charlesm at mcn dot org

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Barkow, Eileen
Sent: Tuesday, July 12, 2011 11:06 AM
To: IBM-MAIN@bama.ua.edu
Subject: running Assembler I/O macro code as AMODE 31, RMODE ANY

We have some old Cobol programs that are being upgraded to Enterprise Cobol
and the users would like to be able to link them as AMODE 31 RMODE ANY.
The problem is that some of these programs call assembler modules to do the
i/o via QSAM and VSAM macros (TESTCB, SHOWCB, GET, PUT, PUTX, etc) and the
only way these can work is by linking everything as AMODE 24, RMODE BELOW.

Is there any way (like by using LE enabled Assembler), that the assembler
macro code can run AMODE 31, RMODE ANY? I know that one way is to reset the
mode dynamically via BSM and other mode setting instructions so that the
data areas can be moved to 24 bit areas before the macros are issued and
then moving them back to AMODE 31 areas to be passed back to the Cobol
programs.
But is there a simpler way to do this?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-12 Thread Barkow, Eileen
Thanks John,
I will look into RMODE(SPLIT).

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
john gilmore
Sent: Tuesday, July 12, 2011 11:43 AM
To: IBM-MAIN@bama.ua.edu
Subject: running Assembler I/O macro code as AMODE 31, RMODE ANY

If you cannot dispense with your RYO I/O routines, use RMODE(SPLIT), which is 
discussed in the z/OS Program Management User's Guide.  I have used it in these 
situations many times. 

John Gilmore Ashland, MA 01721-1817 USA 
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-12 Thread Farley, Peter x23353
Option #1: Use COBOL dynamic CALL (CALL variable-name-containing-module-name) 
to invoke the assembler modules and compile with DATA(24) so that the data 
areas in WORKING-STORAGE are below the line.  Link COBOL as RMODE=ANY and 
AMODE=31.

Option #2: Also uses dynamic COBOL call but compiled with DATA(31).  Use LE 
callable storage subroutines (CEEGTST, CEEFRST) to obtain below-the-line 
storage for data areas to be passed to the assembler subroutines.  Define the 
24-bit data areas in the LINKAGE section, not WORKING-STORAGWE, and use SET 
ADDRESS OF 24-bit-data-area TO pointer-returned-by-LE to address those data 
areas.  Move data from 31-bit WORKING-STORAGE to the LINKAGE-defined 24-bit 
areas to pass to the subroutines.

HTH

Peter

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Barkow, Eileen
> Sent: Tuesday, July 12, 2011 11:06 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: running Assembler I/O macro code as AMODE 31, RMODE ANY
> 
> We have some old Cobol programs that are being upgraded to Enterprise
> Cobol and the users would like to be able to link them as AMODE 31 RMODE
> ANY. The problem is that some of these programs call assembler modules to
> do the i/o via QSAM and VSAM macros (TESTCB, SHOWCB, GET, PUT, PUTX, etc)
> and the only way these can work is by linking everything as AMODE 24,
> RMODE BELOW.
> 
> Is there any way (like by using LE enabled Assembler), that the assembler
> macro code can run AMODE 31, RMODE ANY? I know that one way is to reset
> the mode dynamically via BSM and other mode setting instructions so that
> the data areas can be moved to 24 bit areas before the macros are issued
> and then moving them back to AMODE 31 areas to be passed back to the Cobol
> programs. But is there a simpler way to do this?
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-12 Thread Schumacher, Otto
To fix this problem of allowing all storage to be above the line the Assembler 
I/O subroutines will need to be rewritten. You can have the Cobol program 
compile specifying the compiler option DATA(24) this will indicate to the COBOL 
compile to obtain working storage below the line. This action will allow you to 
call the assembler module that is Amode(24). The Cobol module will then link as 
a Amode 31 Rmode any program.  This compiler option change will allow the 
program code to move above the line but will leave the COBOL programs working 
storage below the line.   

Regards
Otto Schumacher
 
HP Enterprise Services
Infrastructure Specialist
Ahold Account
CICS & Capacity Technical Support
P.O. Box 6462
2000 Wade Hampton Blvd.
LC1-302
Greenville,  South Carolina, 29606
Cell: 864 569--5338
Tel: 864 987-1417
Fax: 864 987-4500
E-mail: otto.schumac...@hp.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Barkow, Eileen
Sent: Tuesday, July 12, 2011 11:06 AM
To: IBM-MAIN@bama.ua.edu
Subject: running Assembler I/O macro code as AMODE 31, RMODE ANY

We have some old Cobol programs that are being upgraded to Enterprise Cobol and
the users would like to be able to link them as AMODE 31 RMODE ANY.
The problem is that some of these programs call assembler modules to do the i/o 
via
QSAM and VSAM macros (TESTCB, SHOWCB, GET, PUT, PUTX, etc) and the only way 
these can work is
by linking everything as AMODE 24, RMODE BELOW.

Is there any way (like by using LE enabled Assembler), that the assembler macro 
code can run
AMODE 31, RMODE ANY? I know that one way is to reset the mode dynamically via 
BSM and other mode setting
instructions so that the data areas can be moved to 24 bit areas before the 
macros are issued and then moving
them back to AMODE 31 areas to be passed back to the Cobol programs.
But is there a simpler way to do this?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html


Re: running Assembler I/O macro code as AMODE 31, RMODE ANY

2011-07-12 Thread Steve Comstock

On 7/12/2011 9:06 AM, Barkow, Eileen wrote:

We have some old Cobol programs that are being upgraded to Enterprise Cobol and
the users would like to be able to link them as AMODE 31 RMODE ANY.
The problem is that some of these programs call assembler modules to do the i/o 
via
QSAM and VSAM macros (TESTCB, SHOWCB, GET, PUT, PUTX, etc) and the only way 
these can work is
by linking everything as AMODE 24, RMODE BELOW.

Is there any way (like by using LE enabled Assembler), that the assembler macro 
code can run
AMODE 31, RMODE ANY? I know that one way is to reset the mode dynamically via 
BSM and other mode setting
instructions so that the data areas can be moved to 24 bit areas before the 
macros are issued and then moving
them back to AMODE 31 areas to be passed back to the Cobol programs.
But is there a simpler way to do this?


VSAM can work AMODE 31 just fine.

For QSAM, there are a number of approaches that allow you
to code file processing in AMODE 31 without switching back
and forth using BSM and the like.

Visit

  http://www.trainersfriend.com/General_content/Book_site.htm

check out these papers:

* Applications Assembler Programming for z

* Writing Reentrant Programs (In Assembler)

* I/O and AMODE 31

they're all free and have some tidbits you might find helpful.



--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* Special promotion: 15% off on all DB2 training classes
scheduled by September 1, taught by year end 2011

* Check out our entire DB2 curriculum at:
http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html