Q. Converting assemblies from 24bit addresses to 31bit ?? 
Author Message
 Q. Converting assemblies from 24bit addresses to 31bit ??

I'm lookin for info on converting 24 bit address mode assemblies to 31 bit
address mode.

I note that HLASM (S390) now supports new instructions (BSSM) to be used in
place of BALR.

Can anyone point me to reference or training materials.

It's been awhile since I got to work in BAL & it I can convince the powers
that be around here that I can
convert some antique DOS/VSE assemblies to play in the 31 bit world I may
get to have quite a bit of fun in the forseeable future.

Thanks in advance, Chris.



Sun, 07 Jan 2001 03:00:00 GMT  
 Q. Converting assemblies from 24bit addresses to 31bit ??

Quote:

> I'm lookin for info on converting 24 bit address mode assemblies to 31 bit
> address mode.

> I note that HLASM (S390) now supports new instructions (BSSM) to be used in
> place of BALR.

That's BASSM. There's also a BAS and a BASR. See any reasonably current XA, ESA
or S/390 Principles of Operation.

Quote:
> It's been awhile since I got to work in BAL

Actually, BAL is almost certainly before your time; anything that you did in
DOS/VSE would have been done with a macro assembler, e.g., Assembler XF
(IFOX00).

--

Shmuel (Seymour J.) Metz
Reply to host nsf (dot) gov, user smetz



Sun, 07 Jan 2001 03:00:00 GMT  
 Q. Converting assemblies from 24bit addresses to 31bit ??
IBM publication GG22-9305, "MVS/XA 31 Bit Assembler Programming" may have what
you are looking for. This is a very old publication. It was published about
1983.
Quote:

>I'm lookin for info on converting 24 bit address mode assemblies to 31 bit
>address mode.

>I note that HLASM (S390) now supports new instructions (BSSM) to be used in
>place of BALR.

>Can anyone point me to reference or training materials.

>It's been awhile since I got to work in BAL & it I can convince the powers
>that be around here that I can
>convert some antique DOS/VSE assemblies to play in the 31 bit world I may
>get to have quite a bit of fun in the forseeable future.

>Thanks in advance, Chris.



Sun, 07 Jan 2001 03:00:00 GMT  
 Q. Converting assemblies from 24bit addresses to 31bit ??
Were you born condescending or did you develop this attitude all by
yourself. I can read, but there is more to the conversion than just the
instructions. Thanks anyway...


Quote:


>> I'm lookin for info on converting 24 bit address mode assemblies to 31
bit
>> address mode.

>> I note that HLASM (S390) now supports new instructions (BSSM) to be used
in
>> place of BALR.

>That's BASSM. There's also a BAS and a BASR. See any reasonably current XA,
ESA
>or S/390 Principles of Operation.

>> It's been awhile since I got to work in BAL

>Actually, BAL is almost certainly before your time; anything that you did
in
>DOS/VSE would have been done with a macro assembler, e.g., Assembler XF
>(IFOX00).

>--

>Shmuel (Seymour J.) Metz
>Reply to host nsf (dot) gov, user smetz



Mon, 08 Jan 2001 03:00:00 GMT  
 Q. Converting assemblies from 24bit addresses to 31bit ??
Shmuel isn't normally condescending or {*filter*} so I wouldn't be too hasty in
taking offense. But anyway, ignoring the potential flamage () this subject
is Waaaaaaaaaay bigger than a bread box.

So big in fact, that when XA was introduced they went to the trouble of
producing a manual "MVS/XA extended addressability guide" or something like
that. I've long since forgotten the pub number. The ESA and OS/390 versions
of it also contain chapters on cross memory services and access register
programming, but I digress....

When you convert an application program from 24 to 31 bit mode you have to
spend some time analyzing the logic and look for possible gotchas. The book
I mention above is a good starting point, but its beyond the scope of this
news group to spell out all of the potential issues.

There is a lot more to consider than residence and I/O because the behavior
of some of the most prosaic instructions (e.g. LA) is quite different in 31
bit mode.

Also, some system macro defaults can leave you astonished unless you're
carefull. e.g. changing from the SVC 10 forms of GETMAIN to the SVC 120 form
changes the (default) storage location to above the line.

When you convert a system program (i.e. one that runs in supervisor state)
there are a whole lot of additional gotchas that may send you scurrying for
a copy of principles of operation. XA completely and utterly changed the I/O
architecture (mainly) but a whole lot of other things besides.

Good luck, and please don't feel you are being brushed off.

Quote:

>Were you born condescending or did you develop this attitude all by
>yourself. I can read, but there is more to the conversion than just the
>instructions. Thanks anyway...



>>> I'm lookin for info on converting 24 bit address mode assemblies to 31
>bit
>>> address mode.

>>> I note that HLASM (S390) now supports new instructions (BSSM) to be used
>in
>>> place of BALR.

>>That's BASSM. There's also a BAS and a BASR. See any reasonably current
XA,
>ESA
>>or S/390 Principles of Operation.

>>> It's been awhile since I got to work in BAL

>>Actually, BAL is almost certainly before your time; anything that you did
>in
>>DOS/VSE would have been done with a macro assembler, e.g., Assembler XF
>>(IFOX00).

>>--

>>Shmuel (Seymour J.) Metz
>>Reply to host nsf (dot) gov, user smetz



Mon, 08 Jan 2001 03:00:00 GMT  
 Q. Converting assemblies from 24bit addresses to 31bit ??

Quote:

> Were you born condescending or did you develop this attitude all by
> yourself.

No, I got that way dealing with ignorant and ungrateful fools.

--

Shmuel (Seymour J.) Metz
Reply to host nsf (dot) gov, user smetz



Mon, 08 Jan 2001 03:00:00 GMT  
 Q. Converting assemblies from 24bit addresses to 31bit ??

Quote:


> > Were you born condescending or did you develop this attitude all by
> > yourself.

> No, I got that way dealing with ignorant and ungrateful fools.

I understand, you didn't *want* to, you *had* to.

Bill {*filter*} <G>



Tue, 09 Jan 2001 03:00:00 GMT  
 Q. Converting assemblies from 24bit addresses to 31bit ??

: > I'm lookin for info on converting 24 bit address mode assemblies to 31 bit
: > address mode.

[snip]
: The next step is much bigger--AMODE(31), RMODE(ANY).  That's where the
: program actually resides above the line (Requires BAS/BASR though you can use
: OPSYNC for this to catch BAL/BALRs within macros).

Um.  I'm not sure what you're thinking about here.  BAL/BALR works just
like BAS/BASR when you're in 31-bit mode (see POP).  This has been true
since 370/XA was first introduced.  There is no reason to use OPSYN (not
OPSYNC) to convert BAL/BALR to BAS/BASR "under the covers."  Don't try to
make things more complicated than they already are.

--
| Edward E. Jaffe                | Voice:      (310) 338-0400 x318     |
| Mgr., Research & Development   | Facsimile:  (310) 338-0801          |

| 9841 Airport Blvd, Suite 700   | IBM Mail:   USS24J24 at IBMMAIL     |        
| Los Angeles, CA 90045          | Web page:   www.phoenixsoftware.com |



Tue, 09 Jan 2001 03:00:00 GMT  
 Q. Converting assemblies from 24bit addresses to 31bit ??

: > : > I'm lookin for info on converting 24 bit address mode assemblies to 31 bit
: > : > address mode.
: > : The next step is much bigger--AMODE(31), RMODE(ANY).  That's where the
: > : program actually resides above the line (Requires BAS/BASR though you can
: use
: > : OPSYNC for this to catch BAL/BALRs within macros).
: >
: > Um.  I'm not sure what you're thinking about here.  BAL/BALR works just
: > like BAS/BASR when you're in 31-bit mode (see POP).  This has been true
: > since 370/XA was first introduced.  There is no reason to use OPSYN (not
: > OPSYNC) to convert BAL/BALR to BAS/BASR "under the covers."  Don't try to
: > make things more complicated than they already are.

: Hi, Ed.

: You probably don't remember me.  But you know all that code you've been
: maintaining over the last ten years--MVS CONDOR, well I wrote that code.

Yes, I remember you.  I passed along your well wishes to Fred.  FYI, I
haven't worked substantially on any of the code you wrote in over nine
years (Sorry).  In the future, please use off-line e-mail for this type of
semi-personal / personal communication.  Fun as it might be, this news
group isn't the place to reminisce about old times.  Please try to stick
to the subject at hand when posting to a public internet forum.

[snip]

: So, as to this particular issue--you're right.  But remember that I was trying
: to be helpful to a person doing a 24-31 bit conversion, and showing that an
: anode(31) rmode(24) conversion is in fact an appropriate first step.

Fair enough.  But you also told him that to get to RMODE(ANY) he needed to
change all of his BAL[R]s to BAS[R]s!  I don't consider that kind of
misinformation to be all that helpful.  I felt it was important to set the
record straight, just in case the original poster might actually have
believed you.  No offense.

: Wishing you the best, Ed.

Same to you.
--
| Edward E. Jaffe                | Voice:      (310) 338-0400 x318     |
| Mgr., Research & Development   | Facsimile:  (310) 338-0801          |

| 9841 Airport Blvd, Suite 700   | IBM Mail:   USS24J24 at IBMMAIL     |        
| Los Angeles, CA 90045          | Web page:   www.phoenixsoftware.com |



Wed, 10 Jan 2001 03:00:00 GMT  
 Q. Converting assemblies from 24bit addresses to 31bit ??


Quote:
>It's been awhile since I got to work in BAL & it I can convince the
>powers that be around here that I can convert some antique
>DOS/VSE assemblies to play in the 31 bit world I may
>get to have quite a bit of fun in the forseeable future.

Sorry to be non-technical here, but what justification wil you give the
"powers that be" ?  From my experience, there is very little to be gained
by converting working application code to AMODE=31 (let alone RMODE=ANY).
The only exceptions I can think of are programs and sub-routines used in
CICS.  In our VSE/MVS conversion practice, we avoid doing any "clean-up"
of this type when we convert assembler programs, it's just not worth it.

I remember having "quite a bit of fun" back in 1988 when I converted my
development environment (including I/O services) to RMODE=ANY, but that
was a long-term investment for the code and for myself.  And that was
system-type code, not application.

So, I understand you want to have a "bit of fun" (don't we all?), but does
your boss know that?

Sorry to rain on your parade!




Wed, 10 Jan 2001 03:00:00 GMT  
 Q. Converting assemblies from 24bit addresses to 31bit ??

says...
Quote:

>> I'm lookin for info on converting 24 bit address mode assemblies to 31 bit
>> address mode.

>Actually, there are two steps here.  The first is to get the program to run
>in AMODE(31), RMODE(24).  That's where the program actually resides below the
>line. This step is not too bad and only requires that you look out for LAs,
>3-byte addresses, and so forth (BAL & BALR still work here).  Doing this step
>will allow the program to be called by other 31-bit programs, and access
>storage or parameters that reside above the line without mode switching.

>The next step is much bigger--AMODE(31), RMODE(ANY).  That's where the
>program actually resides above the line (Requires BAS/BASR though you can use
>OPSYNC for this to catch BAL/BALRs within macros).  This can often times take
>as long as writing the program from scratch.  Especially, if you're dealing
>with things like EXCP, supervisor state, or Key(0) code.  For application
>code, it might not be too bad.

>What's the application?  Insurance?  Accounting?

>Good Luck!  If you have any specific questions I'm sure you can get them
>answered here.

>Regards,

>Richard Harper

Richard,

Thanks for the response. I found an article that concurs with you. I work for
a County Government. Most of the Assemblies are Application Utilities called
form COBOL CICS transaction processors. Being that we still live in the dark
ages and run VSE under VM, the new COBOL for VSE and LE are gonna force us
above the line.

Thanks again for the help.

Chris.



Wed, 10 Jan 2001 03:00:00 GMT  
 Q. Converting assemblies from 24bit addresses to 31bit ??

Quote:



>>It's been awhile since I got to work in BAL & it I can convince the
>>powers that be around here that I can convert some antique
>>DOS/VSE assemblies to play in the 31 bit world I may
>>get to have quite a bit of fun in the forseeable future.

>Sorry to be non-technical here, but what justification wil you give the
>"powers that be" ?  From my experience, there is very little to be
gained
>by converting working application code to AMODE=31 (let alone
RMODE=ANY).
>The only exceptions I can think of are programs and sub-routines used in
>CICS.  In our VSE/MVS conversion practice, we avoid doing any "clean-up"
>of this type when we convert assembler programs, it's just not worth it.

>I remember having "quite a bit of fun" back in 1988 when I converted my
>development environment (including I/O services) to RMODE=ANY, but that
>was a long-term investment for the code and for myself.  And that was
>system-type code, not application.

>So, I understand you want to have a "bit of fun" (don't we all?), but
does
>your boss know that?

>Sorry to rain on your parade!



Gilbert -

You hit the nail on the head. Fortunately for me the assemblies I'm
talkin about are application service utilities for COBOL CICS. With COBOL
for VSE & LE we are starting to experience storage constraint problems
below the line. Now a part of this may be a lack of expertise in
installation and configuration of CICS/COBOL VSE/LE but I'm not a systems
guy, just the only application programmer in our County that knows
assembler.

So I guess I'll get to have my cake & eat it too.



Wed, 10 Jan 2001 03:00:00 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. address mode in assembly program problem

2. How to get burnt MAC address using assembly?

3. Inline Assembly: Getting address of variable

4. HOW TO CONVERT HEX ADDRESS TO DEC.

5. Convert Integer_Address and Address?

6. Convert an address range into an array

7. Converting from real address to segment with offset

8. how to convert ip address to dot notation

9. Convert Assembly

10. converting assembly to higher level language

11. Converting Assembly

12. convert assembly to c/pascal???

 

 
Powered by phpBB® Forum Software