Re: Baseless problem
Sometimes when I'm reading this list or IBM-MAIN I got a feeling like as I was listening to a historic science discussion where now and then Titus Livius and Thucydides pop in with anecdotes... :) (No offence please! I'm very impressed by all.) Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ)
Re: Baseless problem
On Thu, 11 Apr 2013 08:11:19 -0700, Ed Jaffe wrote: On 4/11/2013 7:45 AM, Paul Gilmartin wrote: I believe LOCTR is fairly new. I am curious to know how Mike Shaw observed the literals-physically-first technique implemented using 1976-era assemblers. See pages 4 and 6 of the Assembler H Language manual, GC26-3771-3, dated June, 1974. It is available at http://bitsavers.trailing-edge.com/pdf/ibm/370/asm/GC26-3771-3_asmH_Lang_Sep75.pdf -- Tom Marchant
Re: Baseless problem
On Thu, 11 Apr 2013 23:22:15 +0200, Bernd Oppolzer wrote: I just expanded our local startup macro to support baseless code areas. The standard startup macro especially for main programs generates lots of instructions, that count for some 600 bytes (for example: error handling, buildung a LE environment etc.). So I cannot have a base register for data at the beginning of the program, because there resides this large startup macro. Sure you can. How much of what is generated by that startup macro has to be before the data area location counter is defined? And: the LTORG at the end of the program needs addressibility; Of course. LOCTR takes care of that It's not my dog. -- Tom Marchant
Re: Baseless problem
We have found it very helpful to place an ad-con to the beginning of the module as the first thing in the static area (where the base reg points in a relative-addressing module). Peter Relson z/OS Core Technology Design
Re: Baseless problem
On Thu, 11 Apr 2013 23:43:04 +0200, Bernd Oppolzer wrote: Although the eyecatcher on SAVE (one byte length field at EPA+4 followed by the message) seems to be kind of part of the OS linkage conventions, The language conventions are defined in the Assembler Services Guide. An eyecatcher is not part of it, AFAIK. Same goes for the lack of forward save area chaining by LE - SYSUDUMP is only capable of printing a forward save area chain, if the LSA pointers in the save areas are filled correctly. Not true. SYSUDUMP shows the save areas going forward, then going backward from register 13. Forward chains are not reliable for diagnosis, especially when there are AMODE 64 programs in the mix. Or programs that use the Linkage Stack. And don't get me started on XPLINK. -- Tom Marchant
Re: Baseless problem
... helpful to place an ad-con to the beginning of the module Sure - that takes the human factor out of calculating the correct start -- Martin Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE more at http://www.picapcpu.de
Re: Baseless problem
Thomas, There are a lot of well versed , heavily experienced , aka heavy hitters, here on this listserv. Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Apr 12, 2013, at 4:48 AM, Thomas Berg thomas.b...@swedbank.se wrote: Sometimes when I'm reading this list or IBM-MAIN I got a feeling like as I was listening to a historic science discussion where now and then Titus Livius and Thucydides pop in with anecdotes... :) (No offence please! I'm very impressed by all.) Regards Thomas Berg Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ)
Re: Baseless problem
This is a matter of style to me and experience level. I learned the data areas and liberals at the tail end of your code ...always worked for me. Doesn't mean that's the only way to to do II Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Apr 12, 2013, at 8:24 AM, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Thu, 11 Apr 2013 23:22:15 +0200, Bernd Oppolzer wrote: I just expanded our local startup macro to support baseless code areas. The standard startup macro especially for main programs generates lots of instructions, that count for some 600 bytes (for example: error handling, buildung a LE environment etc.). So I cannot have a base register for data at the beginning of the program, because there resides this large startup macro. Sure you can. How much of what is generated by that startup macro has to be before the data area location counter is defined? And: the LTORG at the end of the program needs addressibility; Of course. LOCTR takes care of that It's not my dog. -- Tom Marchant
Re: Baseless problem
On Fri, 12 Apr 2013 09:27:37 -0400, Scott Ford wrote: This is a matter of style to me and experience level. I learned the data areas and liberals at the tail end of your code Right. If you *want* to put your constants and literals at the end, that's your business. But when someone says that they *can't* put them at the beginning, that's when I suggest an option. -- Tom Marchant
Re: Baseless problem
I totally agree..Tom I think one has to be open to different techniques and try them Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Apr 12, 2013, at 9:37 AM, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Fri, 12 Apr 2013 09:27:37 -0400, Scott Ford wrote: This is a matter of style to me and experience level. I learned the data areas and liberals at the tail end of your code Right. If you *want* to put your constants and literals at the end, that's your business. But when someone says that they *can't* put them at the beginning, that's when I suggest an option. -- Tom Marchant
Re: Baseless problem
On 4/12/2013 7:43 AM, Scott Ford wrote: I totally agree..Tom I think one has to be open to different techniques and try them It's a constant balance thing. When you have a technique that works for you, then there's one less set of decisions you need to make, allowing you to focus on the current task. However, you could be missing an alternative technique that has major benefits, so you have to consider the alternatives. But you can't afford to become paralyzed by looking at an infinite number of options. That's one of the benefits of this list: you can learn from people who have walked down a path and decide if it's worth your while to explore that path based on what is reported here. Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Apr 12, 2013, at 9:37 AM, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Fri, 12 Apr 2013 09:27:37 -0400, Scott Ford wrote: This is a matter of style to me and experience level. I learned the data areas and liberals at the tail end of your code Right. If you *want* to put your constants and literals at the end, that's your business. But when someone says that they *can't* put them at the beginning, that's when I suggest an option. -- Tom Marchant -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html
Re: Baseless problem
Steve, A big absolutely I am a big learner...taught myself just a ton of programming languages. Its a nack Scott J Ford Software Engineer http://www.identityforge.com/ From: Steve Comstock st...@trainersfriend.com To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Friday, April 12, 2013 9:53 AM Subject: Re: Baseless problem On 4/12/2013 7:43 AM, Scott Ford wrote: I totally agree..Tom I think one has to be open to different techniques and try them It's a constant balance thing. When you have a technique that works for you, then there's one less set of decisions you need to make, allowing you to focus on the current task. However, you could be missing an alternative technique that has major benefits, so you have to consider the alternatives. But you can't afford to become paralyzed by looking at an infinite number of options. That's one of the benefits of this list: you can learn from people who have walked down a path and decide if it's worth your while to explore that path based on what is reported here. Scott ford http://www.identityforge.com/ Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Apr 12, 2013, at 9:37 AM, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Fri, 12 Apr 2013 09:27:37 -0400, Scott Ford wrote: This is a matter of style to me and experience level. I learned the data areas and liberals at the tail end of your code Right. If you *want* to put your constants and literals at the end, that's your business. But when someone says that they *can't* put them at the beginning, that's when I suggest an option. -- Tom Marchant -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html
Re: Baseless problem
Jon, I understand what Tom said no problemo Scott J Ford Software Engineer http://www.identityforge.com/ From: Jon Perryman jperr...@pacbell.net To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Friday, April 12, 2013 10:23 AM Subject: Re: Baseless problem Tom is not saying you should change your coding style. You leave the data areas and literals at the end of your source code. You add LOCTR statements into your program to change generated machine code sequence. Jon Perryman - Original Message From: Scott Ford scott_j_f...@yahoo.com This is a matter of style to me and experience level. I learned the data areas and liberals at the tail end of your code ...always worked for me. Doesn't mean that's the only way to to do II Scott ford Sure you can. How much of what is generated by that startup macro has to be before the data area location counter is defined? And: the LTORG at the end of the program needs addressibility; Of course. LOCTR takes care of that -- Tom Marchant
Re: Baseless problem
The quality of this discussion would be improved if a distinction between 1) the sequence of things in a source program and 2) the sequence of the corresponding entities in an assembled object program were made and observed with some care. John Gilmore, Ashland, MA 01721 - USA
Re: Baseless problem
On Fri, 12 Apr 2013 07:23:48 -0700, Jon Perryman wrote: Tom is not saying you should change your coding style. Right. You leave the data areas and literals at the end of your source code. You add LOCTR statements into your program to change generated machine code sequence. I would say You can. I had to do this just last week for a program that I was modifying. The change was big enough to cause the program to exceed the addressability with the base registers, so I converted it to use relative addressing. Our standards call for the base register to point to the beginning of the module, so I used LOCTR instructions to move the data areas to the beginning of the CSECT and changed all of the branches to relative branches. It was relatively painless to make the change. In fact, it was easier (IMO) than it would have been to move all of the definitions of data to the end of the program and change the way that the base registers are set. -- Tom Marchant
Re: Baseless problem
Jon, Sorry if I offended anyone. That was not my intent. NEED TO was not meant to dictate what vendors must do. I was the one who . - It was my understanding (and English is not my native language) of what you posted and my curiosity (but certainly no offence felt here). I also thought maybe there are rules (and it turned out during the late postings there are some but not for this) for z/OS only people'(watch my modified sig-line). -- Martin supporter of the other op-sys, that runs CICS, HLASM, and MQ, and a few others precious supplements of the base op-sys.
Re: Baseless problem
On 4/12/2013 9:27 AM, Scott Ford wrote: This is a matter of style to me and experience level. I learned the data areas and liberals at the tail end of your code ...always worked for me. Doesn't mean that's the only way to to do II Yes, those d**n liberals sneak in everywhere g My pet peeve are programs where data areas, mostly macro expansions, have to precede the code to make macro references work correctly. In the worst case I ran into a program with 60 pages of expansions, one and one-half pages of code, then more data and the cross-reference. I'd rather locate a needle in a haystack! Gerhard Postpischil Bradford, Vermont
Re: Baseless problem
I would like to thank you all for your suggestions and for this discussion. The reason why I will stay with my current logic (the large startup macro at the beginning, followed by the code, followed by the static definitions) is that there are several thousand existant programs which are not yet baseless and which follow this convention, and I need them to compile without modification. The startup macro has got some new keyword parms which simply puts the using points at another place (away from the module start, to the start of the static data area) and so it makes the code area baseless - nothing else to do for the developers - if the code itself and the macros which are used can tolerate this. What I do to support this: IEABRCX DEFINE and SYSSTATE ARCHLVL=2 in the startup macro - iff the new keyword parms are set. Now I hope that the remaining ca. 50 ASSEMBLER developers will use this ... and will step by step change their modules by using the new keyword parm (most of the developers are PL/1 developers, not ASSEMBLER). Kind regards Bernd Am 12.04.2013 16:23, schrieb Jon Perryman: Tom is not saying you should change your coding style. You leave the data areas and literals at the end of your source code. You add LOCTR statements into your program to change generated machine code sequence. Jon Perryman - Original Message From: Scott Ford scott_j_f...@yahoo.com This is a matter of style to me and experience level. I learned the data areas and liberals at the tail end of your code ...always worked for me. Doesn't mean that's the only way to to do II Scott ford Sure you can. How much of what is generated by that startup macro has to be before the data area location counter is defined? And: the LTORG at the end of the program needs addressibility; Of course. LOCTR takes care of that -- Tom Marchant
Re: Baseless problem
Jon, Enough been said about the reason and the cause (and solutions) But who dictates techniques for vendors? While your points are okay- the trick to have the definitions right at the beginning of the module (with just a J in front) is something that makes sense for everyone. If you ever tried to calculate offset in a DOB-program (data only base) from the start of the LTORG (or wherever the base points to) knows what I mean. Credit for the technique goes to Ed J. Martin
Re: Baseless problem
I agree. It is very nice. sigh Now to change my habits ... again. /sigh On Thu, Apr 11, 2013 at 6:37 AM, Martin Trübner mar...@pi-sysprog.de wrote: Jon, Enough been said about the reason and the cause (and solutions) But who dictates techniques for vendors? While your points are okay- the trick to have the definitions right at the beginning of the module (with just a J in front) is something that makes sense for everyone. If you ever tried to calculate offset in a DOB-program (data only base) from the start of the LTORG (or wherever the base points to) knows what I mean. Credit for the technique goes to Ed J. Martin -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown
Re: Baseless problem
On Apr 11, 2013, at 06:40, John McKown wrote: I agree. It is very nice. sigh Now to change my habits ... again. /sigh LOCTR can alleviate that impact. On Thu, Apr 11, 2013 at 6:37 AM, Martin Trübner mar...@pi-sysprog.de wrote: Jon, Enough been said about the reason and the cause (and solutions) But who dictates techniques for vendors? While your points are okay- the trick to have the definitions right at the beginning of the module (with just a J in front) is something that makes sense for everyone. If you ever tried to calculate offset in a DOB-program (data only base) from the start of the LTORG (or wherever the base points to) knows what I mean. Credit for the technique goes to Ed J. -- gil
Re: Baseless problem
On 4/11/2013 5:37 AM, Martin Trübner wrote: Jon, Enough been said about the reason and the cause (and solutions) But who dictates techniques for vendors? While your points are okay- the trick to have the definitions right at the beginning of the module (with just a J in front) is something that makes sense for everyone. If you ever tried to calculate offset in a DOB-program (data only base) from the start of the LTORG (or wherever the base points to) knows what I mean. Interesting how COBOL-ish that part is: data division before procedure division. Credit for the technique goes to Ed J. Well, Ed's super sharp but I think that technique has been around a while. Martin -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html
Re: Baseless problem
From: Steve Comstock st...@trainersfriend.com To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Thursday, April 11, 2013 7:47:33 AM Subject: Re: Baseless problem Interesting how COBOL-ish that part is: data division before procedure division. “Plus ça change, plus c’est la même chose.” (perhaps) Bill Fairchild Franklin, TN
Re: Baseless problem
On Thu, Apr 11, 2013 at 8:47 AM, Steve Comstock st...@trainersfriend.comwrote: ...snip...Well, Ed's super sharp but I think that technique has been around a while. Amen. I saw it first in code in 1976, with the eyecatcher preceded by a one-byte length field for the eyecatcher. That one byte length is used by the dump formatter to print the eyecatchers when formatting the save area chain. -- Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Baseless problem
On 4/11/2013 6:52 AM, Mike Shaw wrote: On Thu, Apr 11, 2013 at 8:47 AM, Steve Comstock st...@trainersfriend.comwrote: ...snip...Well, Ed's super sharp but I think that technique has been around a while. Amen. I saw it first in code in 1976, with the eyecatcher preceded by a one-byte length field for the eyecatcher. That one byte length is used by the dump formatter to print the eyecatchers when formatting the save area chain. The oldest assembler I ever used was IFOX00. ISTR, it did not have support for LOCTR but my memory could be faulty. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: Baseless problem
On Apr 11, 2013, at 08:32, Ed Jaffe wrote: The oldest assembler I ever used was IFOX00. ISTR, it did not have support for LOCTR but my memory could be faulty. I believe LOCTR is fairly new. Some of my co-workers are old enough not to know about it. Bitsavers would probably know, but why bother. I once played with LOCTR until I created an unresolvable expression in an address constant (no base-displacement involved) with no symbols having been referenced prior to their definitions. -- gil
Re: Baseless problem
The oldest assembler I ever used was IFOX00. ISTR, it did not have support for LOCTR but my memory could be faulty. I cut my teeth on ACP. ACP assembler code included set symbols like BG15 (possibly still there in zTPF). This naming is a relic of an Assembler that, AFAIK, pre-dated OS/360. et symbol names were restricted (BASIC-like) to A/B/C (arithmetic, etc) G/L (global/local) then a number. Best regards, Steve Hobson Je me presse de rire de tout, de peur d'être obligé d'en pleurer Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Baseless problem
On Thu, Apr 11, 2013 at 10:32 AM, Ed Jaffe edja...@phoenixsoftware.comwrote: The oldest assembler I ever used was IFOX00. ISTR, it did not have support for LOCTR but my memory could be faulty. http://www.phoenixsoftware.com/ You are of course correct; my reference was to eyecatcher placement after the initial instruction in the CSECT, which was a branch around the eyecatcher and its length byte. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd.
Re: Baseless problem
On 4/11/2013 7:45 AM, Paul Gilmartin wrote: I believe LOCTR is fairly new. Some of my co-workers are old enough not to know about it. Bitsavers would probably know, but why bother. Why bother? I am curious to know how Mike Shaw observed the literals-physically-first technique implemented using 1976-era assemblers. Using HLASM, I don't know how to make literals physically precede the code that declares them without the use of LOCTR, but I'm willing to learn. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: Baseless problem
On 4/11/2013 7:55 AM, Mike Shaw wrote: You are of course correct; my reference was to eyecatcher placement after the initial instruction in the CSECT, which was a branch around the eyecatcher and its length byte. Ahhh. That's where the confusion comes from! :) See pages 48-50 of my 2011 SHARE in Anaheim Jumpify presentation: ftp://ftp.phoenixsoftware.com/pub/demo/Jumpify_Your_Code_2011.pdf Getting the base register pointing to the physical start of a no-code-base program is the focus of those three slides. The format of the eyecatcher is unimportant. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: Baseless problem
How about something like this: BEGIN CSECT USING BEGIN ,15 LR 12,15 DROP 1 5 USING BEGIN,12 B ORIGIN2 ORIGIN1 EQU * ORG *+1000 ORIGIN2 put all your executable code here, which includes references using base registers (this was 1976, remember) . end of executable code ORG ORIGIN1 LTORG , ORG , resume executable code Not that this would be useful, but I thihk this would get all the literals defined at the beginning. Anyway, IBM has been putting a Branch instruction at the beginning of their modules, followed by much eyecatcher info, for a lot longer than baseless coding has been promulgated. And doing that did not eliminate their need for base registers, either. Bill Fairchild Franklin, TN - Original Message - From: Ed Jaffe edja...@phoenixsoftware.com To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Thursday, April 11, 2013 10:11:19 AM Subject: Re: Baseless problem On 4/11/2013 7:45 AM, Paul Gilmartin wrote: I believe LOCTR is fairly new. Some of my co-workers are old enough not to know about it. Bitsavers would probably know, but why bother. Why bother? I am curious to know how Mike Shaw observed the literals-physically-first technique implemented using 1976-era assemblers. Using HLASM, I don't know how to make literals physically precede the code that declares them without the use of LOCTR, but I'm willing to learn. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/
Re: Baseless problem
He said that he did, IIRC. On Thu, Apr 11, 2013 at 10:56 AM, Steve Comstock st...@trainersfriend.com wrote: On 4/11/2013 9:33 AM, Ed Jaffe wrote: snip I wonder if the OP got his problem solved. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com
Re: Baseless problem
Guys: I wanted to say a BIG THX...I got my code to assemble still working thru design and coding issues..but hey what's life without a challenge or two or three... Heres my new code..I had to changes things for obivious reasons. SAMPLE01 AMODE 31 SAMPLE01 RMODE ANY YREGS PRINT OFF SYSSTATE ARCHLVL=2 IEABRCX DEFINE PRINT ON J BEGIN PROLOG LOCTR DC C'SAMPLE01 - xxx V4.7.0.2' DC C'Assembled Date Time: SYSDATE SYSTIME' DC C'Copyright (C), Identityforge,LLC' DC C'All rights reserved' CODEBG1 LOCTR BEGIN DS 0H SAVE (14,12) save regs coming in LR R12,R15 AHI R12,CONST-BEGIN USING CONST,R12 LR R10,R1 USING WRKDSECT,R11 base parameter map USING EVXPL,R10 base parameter map L R4,EVXFLAGS exit flag address . .. . CONST DC 0D .(literal constants) LTORG DATALOC1 LOCTR DYNAMIC DSECT SAVEAREA DS 18F register save area ... ... DYNSIZE EQU *-DYNAMIC length of DSECT DATALOC2 LOCTR WRKDSECT DSECT WRKSIZE EQU *-WRKDSECT length of DSECT IHAPSA IHAASCB IHAASXB IRREVXP IEANTASM IHAACEE IKJTSB LIST=YES,EXT=YES Something I would also like to comment on and share. I saw Jon Perryman's comments. I thank him for the suggestion but still as a vendor we are the ones responsible for our code. Can it be done better, of course, but there is a way to suggest that. Over the last couple of days a customer , tried to tell us that every vendor had to have their modules identify the vendor by its first three characters of a name. There were a few other ill-educated suggestions. I understand everyone has to learn but again there is a respectful way of suggesting this to a company, i.e.; vendor. I would never try to tell a vendor, i.e.; IBM, how to code or what to do, they have suggestion forms and forums for that. Maybe I am too old school.. Regards, Scott J Ford Software Engineer http://www.identityforge.com/ aka ...somewhere lost in NJ From: John McKown john.archie.mck...@gmail.com To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Thursday, April 11, 2013 12:54 PM Subject: Re: Baseless problem He said that he did, IIRC. On Thu, Apr 11, 2013 at 10:56 AM, Steve Comstock st...@trainersfriend.com wrote: On 4/11/2013 9:33 AM, Ed Jaffe wrote: snip I wonder if the OP got his problem solved. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com
Re: Baseless problem
Ed Jaffe noted... The oldest assembler I ever used was IFOX00. ISTR, it did not have support for LOCTR but my memory could be faulty. I think your memory is correct. As I remember the IFOX assembler used basically the four-pass structure of Assembler F. It was developed and supported by a group in Lidingo Sweden (a suburb of Stockholm?), and its popular publications were done by Jan Sandzelius. (The Swedish group attended several SHARE conferences while they were learning skills transfers from the assembler team in San Jose.) I believe LOCTR was introduced with Assembler H. Due to its having merged conditional assembly and ordinary-assembly pass 1, any time a location counter discontinuity was found it had to establish LOCTR-like temporary location counter that ASMH then resolved at the end of pass 1 in an interlude. The LOCTR instruction was apparently a public exposure of this internal facility. More than you wanted to know, maybe...
Re: Baseless problem
On 4/11/2013 7:37 AM, Martin Trübner wrote: While your points are okay- the trick to have the definitions right at the beginning of the module (with just a J in front) is something that makes sense for everyone. If you ever tried to calculate offset in a DOB-program (data only base) from the start of the LTORG (or wherever the base points to) knows what I mean. The easiest way I've found to simplify debugging is to use page alignment (at the start, add a PUNCH ' ORDER csect(P) '). While IBM actively discourages this (IEBCOPY throws a hissy fit for page aligned modules), having the last three bytes of a dump address agree with the assembled address is an enormous time-saver. Gerhard Postpischil Bradford, Vermont
Re: Baseless problem
Mike Shaw wrote: Amen. I saw it first in code in 1976, with the eyecatcher preceded by a one-byte length field for the eyecatcher. That one byte length is used by the dump formatter to print the eyecatchers when formatting the save area chain. ... and the eyecatcher, the 3rd operand of SAVE reg[,T,*] 181 SAVE (14,12),T,'ACMDXL00 VERS ASMDTE' 182+ B 24(0,15) BRANCH AROUND ID 01-SAVE 183+ DCAL1(19) LENGTH OF IDENTIFIER 01-SAVE 184+ DCCL8'ACMDXL00' IDENTIFIER 01-SAVE 185+ DCCL8' 1.1 030' IDENTIFIER 01-SAVE 186+ DCCL3'102' IDENTIFIER 01-SAVE 187+ STM 14,12,12(13) SAVE REGISTERS 01-SAVE 188 LRR12,R15 LOAD PGM BASE REG = EP ADDRESS The above was assembled 10 years ago by HLASM R4.0. The SAVE macro is at least 45 years old. Frequently the bytes following the eyecatcher / dump-id were used for version/PTF id's and for global address vector tables. Andreas F. Geissbuehler
Re: Baseless problem
On 11 April 2013 10:32, Ed Jaffe edja...@phoenixsoftware.com wrote: The oldest assembler I ever used was IFOX00. ISTR, it did not have support for LOCTR but my memory could be faulty. It matches mine. It's worth remembering that ASMH predates IFOX00. (Well, as far as customer availability goes; I have no idea what went on inside IBM.) I have never understood the point of IFOX00; it appears to be a reimplemention from scratch to the IEUASM specs, with a couple of trivial functional enhancements, and using reentrant code. Compared to IEUASM it has no significant performance advantage, appears not to exploit any particular aspects of virtual storage, the supported macro and assembler language is essentially identical, diagnostics are no better, and so on. I can only guess at the internal politics in play at the time that must have led to this project, when ASMH already existed and offered so much more. IBM's usual internal competition, I suppose, but in such a small subject area... On the more on-topic matter of jumpifying and putting data at the start of a module, it bears keeping in mind that it does locality of reference no good to have a single branch/jump instruction at the start of a module, followed by a large amount of data, and then code continuing way down. While no-one may be paging the way they used to these days, it still shouldn't be encouraged, and hopping down the pages with one instruction reference each is not the thing to do. Even on the smaller scale and much faster resolution time of cache lines, it's probably not such a good thing. Tony H.
Re: Baseless problem
Tony Harminc wonders... I can only guess at the internal politics in play at the time that must have led to this project, when ASMH already existed and offered so much more. IBM's usual internal competition, I suppose, but in such a small subject area... AFAIR... core..! hmm virtual memory, sysgens and $$$ With the arrival of the 512K 370/155 our boss allowed a partition size increase from 80K to 128K. Then the DAT-box and SVS. IFOX00 worked but was awefully slow. ASMH costed money and needed 200K+ to assemble anything substantial. The free ASMG from University of Waterloo became our saviour. FWIW, more details in this post by Peter, dated 29 Mar 2008 18:40 here: http://comments.gmane.org/gmane.comp.emulators.hercules390.mvs/6553 A lot of oddball-stuff of today was shaped by the physical (and IBMs legal!) constraints at the time it was conceived. Andreas F. Geissbuehler
Re: Baseless problem
Slightly different opinion on my side: I just expanded our local startup macro to support baseless code areas. The standard startup macro especially for main programs generates lots of instructions, that count for some 600 bytes (for example: error handling, buildung a LE environment etc.). So I cannot have a base register for data at the beginning of the program, because there resides this large startup macro. And: the LTORG at the end of the program needs addressibility; there also go the definitions created by the structured programming macros, which are used in the code section. So I did the following: a) establish temporary base regs using R15 to support the startup macro - it was not possible to get all the startup code baseless b) drop temporary base c) force the developers to have code first, then data d) establish base regs only for the data section So the code area is baseless and may grow. The data area starts with a special macro which defines the base address, which is used in the USING in the startup code. For finding the variables in the dump, you should use the offsets in the instructions, not the offsets in the assembly list - or: you have to add the distance of the data area base. Other features: you specify an arbitrary number of base regs in the startup macro. and you have 3 options: BASREG=CODE: the base regs cover the code area, from the start of the CSECT BASREG=CODDAT: first base reg covers the code area, the second and the following cover the data area BASREG=DATA: the base regs cover the data area (true baseless code area) The definition and initialization of the registers is done by the startup macro code. Our ASSEMBLER coders are accustomed to use ASSEMBLER almost like a high level language - they normally don't want to deal with such things like addressibility issues. That's why we normally use the structured programming macros exclusively, too. Kind regards Bernd Am 11.04.2013 13:37, schrieb Martin Trübner: Jon, Enough been said about the reason and the cause (and solutions) But who dictates techniques for vendors? While your points are okay- the trick to have the definitions right at the beginning of the module (with just a J in front) is something that makes sense for everyone. If you ever tried to calculate offset in a DOB-program (data only base) from the start of the LTORG (or wherever the base points to) knows what I mean. Credit for the technique goes to Ed J. Martin
Re: Baseless problem
Although the eyecatcher on SAVE (one byte length field at EPA+4 followed by the message) seems to be kind of part of the OS linkage conventions, no other IBM language processor like the PL/1 compiler or LE ever used it - I never understood this. This discourages the use of SYSUDUMP for error diagnose heavily. Same goes for the lack of forward save area chaining by LE - SYSUDUMP is only capable of printing a forward save area chain, if the LSA pointers in the save areas are filled correctly. For decades, we tried to restore the forward chain on every call, by calling special ASSEMBLER routines after every PL/1 procedure entry; just to have the SYSUDUMP forward chain in the case of an error. What a mess! In the end, we removed this, and wrote our own error recovery and dump printing routine, which we use in every environment, and which does not rely on the forward chain, like CEEDUMP - it restores the forward chain only in the error situation, when needed - for us it works better than CEEDUMP, and it also works in environments where we don't have LE - in an LE environment, the dump printing routine is called by an LE exit and replaces CEEDUMP. I sometimes had the impression that the designers of LE never talked with the opsys people and both didn't talk with the compiler people and vice versa ... how sad ... Ok, I see one possible reason for this: LE has to work on EVERY opsys, and so may not rely on features that are specific to a special opsys. This may be the reasons for some of the trouble we have here. Kind regards Bernd Am 11.04.2013 20:23, schrieb Andreas F. Geissbuehler: Mike Shaw wrote: Amen. I saw it first in code in 1976, with the eyecatcher preceded by a one-byte length field for the eyecatcher. That one byte length is used by the dump formatter to print the eyecatchers when formatting the save area chain. ... and the eyecatcher, the 3rd operand of SAVE reg[,T,*] 181 SAVE (14,12),T,'ACMDXL00 VERS ASMDTE' 182+ B 24(0,15) BRANCH AROUND ID 01-SAVE 183+ DCAL1(19) LENGTH OF IDENTIFIER 01-SAVE 184+ DCCL8'ACMDXL00' IDENTIFIER 01-SAVE 185+ DCCL8' 1.1 030' IDENTIFIER 01-SAVE 186+ DCCL3'102' IDENTIFIER 01-SAVE 187+ STM 14,12,12(13) SAVE REGISTERS 01-SAVE 188 LRR12,R15 LOAD PGM BASE REG = EP ADDRESS The above was assembled 10 years ago by HLASM R4.0. The SAVE macro is at least 45 years old. Frequently the bytes following the eyecatcher / dump-id were used for version/PTF id's and for global address vector tables. Andreas F. Geissbuehler -- Bernd Oppolzer --- *Oppolzer-Informatik * Dipl. Inf. Bernd Oppolzer Bärenhofstraße 23 70771 Leinfelden-Echterdingen --- Tel.: +49 711 2272522 priv.: +49 711 7949590 eMail: bernd.oppol...@t-online.de mailto:bernd.oppol...@t-online.de --- Für Umsatzsteuerzwecke: SteuerNr.: 97 076 / 29921 USt-ID-Nr.: DE 147 700 393 --- Jubiläumsjahr 2013: 30 Jahre Oppolzer-Informatik
Re: Baseless problem
Reading again: there is no problem finding the (static) data, even if the USING point is not at the beginning of the module; if you have the load point of the module, which you get easily from CDE/XTLST, then you add the offsets of the variables from the CSECT. Oh, I see, you are VSE normally - don't know how easy or difficult it is to get the load points of the modules in a VSE environment - but at least the load point of the abending module should be present at the top of a dump, even in VSE. Kind regards Bernd Am 11.04.2013 23:22, schrieb Bernd Oppolzer: For finding the variables in the dump, you should use the offsets in the instructions, not the offsets in the assembly list - or: you have to add the distance of the data area base.
Re: Baseless problem
LOCTR has been around since at least the mid-1980s. I had to debug a full-screen editor that used it heavily. This would have been the H-Assembler with SLAC mods. Lloyd - Original Message From: Paul Gilmartin paulgboul...@aim.com To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Thu, April 11, 2013 10:48:09 AM Subject: Re: Baseless problem On Apr 11, 2013, at 08:32, Ed Jaffe wrote: The oldest assembler I ever used was IFOX00. ISTR, it did not have support for LOCTR but my memory could be faulty. I believe LOCTR is fairly new. Some of my co-workers are old enough not to know about it. Bitsavers would probably know, but why bother. I once played with LOCTR until I created an unresolvable expression in an address constant (no base-displacement involved) with no symbols having been referenced prior to their definitions. -- gil
Re: Baseless problem
On 11/04/2013 20:23, Tony Harminc wrote: On 11 April 2013 10:32, Ed Jaffe edja...@phoenixsoftware.com wrote: The oldest assembler I ever used was IFOX00. ISTR, it did not have support for LOCTR but my memory could be faulty. It matches mine. It's worth remembering that ASMH predates IFOX00. (Well, as far as customer availability goes; I have no idea what went on inside IBM.) I have never understood the point of IFOX00; it appears to be a reimplemention from scratch to the IEUASM specs, with a couple of trivial functional enhancements, and using reentrant code. Compared to IEUASM it has no significant performance advantage, appears not to exploit any particular aspects of virtual storage, the supported macro and assembler language is essentially identical, diagnostics are no better, and so on. It will assemble the code the old GCC370 compiler spits out and I don't think IUEASM will. Certainly ASMG failed when I tried it I can only guess at the internal politics in play at the time that must have led to this project, when ASMH already existed and offered so much more. IBM's usual internal competition, I suppose, but in such a small subject area... On the more on-topic matter of jumpifying and putting data at the start of a module, it bears keeping in mind that it does locality of reference no good to have a single branch/jump instruction at the start of a module, followed by a large amount of data, and then code continuing way down. While no-one may be paging the way they used to these days, it still shouldn't be encouraged, and hopping down the pages with one instruction reference each is not the thing to do. Even on the smaller scale and much faster resolution time of cache lines, it's probably not such a good thing. Tony H.
Re: Baseless problem
Scott, A couple more suggestions. 1. add 'ieabrcx enable' (or maybe it was snipped) 2. use larl 12,const instead of lr/ahi - it will make amode 64 conversion easier 3. limit the using range to avoid base register bleed beyond the intended range 'using (const,constend),12' 4. both dataloc1/2 loctr's have no purpose when they are just followed by dsects 5. use the noprint option on the print statements to keep the listing cleaner ...chris. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Scott Ford Sent: Thursday, April 11, 2013 12:13 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Baseless problem Guys: I wanted to say a BIG THX...I got my code to assemble still working thru design and coding issues..but hey what's life without a challenge or two or three... Heres my new code..I had to changes things for obivious reasons. SAMPLE01 AMODE 31 SAMPLE01 RMODE ANY YREGS PRINT OFF SYSSTATE ARCHLVL=2 IEABRCX DEFINE PRINT ON J BEGIN PROLOG LOCTR DCC'SAMPLE01 - xxx V4.7.0.2' DCC'Assembled Date Time: SYSDATE SYSTIME' DCC'Copyright (C), Identityforge,LLC' DCC'All rights reserved' CODEBG1 LOCTR BEGINDS0H SAVE (14,12) save regs coming in LRR12,R15 AHI R12,CONST-BEGIN USING CONST,R12 LRR10,R1 USING WRKDSECT,R11 base parameter map USING EVXPL,R10base parameter map L R4,EVXFLAGS exit flag address . .. . CONSTDC0D .(literal constants) LTORG DATALOC1 LOCTR DYNAMIC DSECT SAVEAREA DS18F register save area ... ... DYNSIZE EQU *-DYNAMIC length of DSECT DATALOC2 LOCTR WRKDSECT DSECT WRKSIZE EQU *-WRKDSECT length of DSECT IHAPSA IHAASCB IHAASXB IRREVXP IEANTASM IHAACEE IKJTSB LIST=YES,EXT=YES Something I would also like to comment on and share. I saw Jon Perryman's comments. I thank him for the suggestion but still as a vendor we are the ones responsible for our code. Can it be done better, of course, but there is a way to suggest that. Over the last couple of days a customer , tried to tell us that every vendor had to have their modules identify the vendor by its first three characters of a name. There were a few other ill-educated suggestions. I understand everyone has to learn but again there is a respectful way of suggesting this to a company, i.e.; vendor. I would never try to tell a vendor, i.e.; IBM, how to code or what to do, they have suggestion forms and forums for that. Maybe I am too old school.. Regards, Scott J Ford Software Engineer http://www.identityforge.com/ aka ...somewhere lost in NJ From: John McKown john.archie.mck...@gmail.com To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Thursday, April 11, 2013 12:54 PM Subject: Re: Baseless problem He said that he did, IIRC. On Thu, Apr 11, 2013 at 10:56 AM, Steve Comstock st...@trainersfriend.com wrote: On 4/11/2013 9:33 AM, Ed Jaffe wrote: snip I wonder if the OP got his problem solved. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com
Re: Baseless problem
Bernd Oppolzer schrieb: ... the OS linkage conventions, no other IBM language processor like the PL/1 compiler or LE ever used it - I never understood this. LE was a game changer. Prior to LE almost all programs and modules adhered to __one and the same set__ of rules, including IBM access methods and supervisor services. Andreas F. Geissbuehler
Re: Baseless problem
Andreas: Amen to that. I am working with LE now ..a lot of serious differences, especially when ppl dont run the right run options.. like STACK() ... Scott J Ford Software Engineer http://www.identityforge.com/ From: Andreas F. Geissbuehler afg0...@videotron.ca To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Thursday, April 11, 2013 8:40 PM Subject: Re: Baseless problem Bernd Oppolzer schrieb: ... the OS linkage conventions, no other IBM language processor like the PL/1 compiler or LE ever used it - I never understood this. LE was a game changer. Prior to LE almost all programs and modules adhered to __one and the same set__ of rules, including IBM access methods and supervisor services. Andreas F. Geissbuehler
Re: Baseless problem
Chris: thanks for the suggestion much appreciated...I am writing more code tonight...so i will let you all now how it comes out Scott J Ford Software Engineer http://www.identityforge.com/ From: Webster, Chris chris_webs...@bmc.com To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Thursday, April 11, 2013 2:11 PM Subject: Re: Baseless problem Scott, A couple more suggestions. 1. add 'ieabrcx enable' (or maybe it was snipped) 2. use larl 12,const instead of lr/ahi - it will make amode 64 conversion easier 3. limit the using range to avoid base register bleed beyond the intended range 'using (const,constend),12' 4. both dataloc1/2 loctr's have no purpose when they are just followed by dsects 5. use the noprint option on the print statements to keep the listing cleaner ...chris. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Scott Ford Sent: Thursday, April 11, 2013 12:13 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Baseless problem Guys: I wanted to say a BIG THX...I got my code to assemble still working thru design and coding issues..but hey what's life without a challenge or two or three... Heres my new code..I had to changes things for obivious reasons. SAMPLE01 AMODE 31 SAMPLE01 RMODE ANY YREGS PRINT OFF SYSSTATE ARCHLVL=2 IEABRCX DEFINE PRINT ON J BEGIN PROLOG LOCTR DC C'SAMPLE01 - xxx V4.7.0.2' DC C'Assembled Date Time: SYSDATE SYSTIME' DC C'Copyright (C), Identityforge,LLC' DC C'All rights reserved' CODEBG1 LOCTR BEGIN DS 0H SAVE (14,12) save regs coming in LR R12,R15 AHI R12,CONST-BEGIN USING CONST,R12 LR R10,R1 USING WRKDSECT,R11 base parameter map USING EVXPL,R10 base parameter map L R4,EVXFLAGS exit flag address . .. . CONST DC 0D .(literal constants) LTORG DATALOC1 LOCTR DYNAMIC DSECT SAVEAREA DS 18F register save area ... ... DYNSIZE EQU *-DYNAMIC length of DSECT DATALOC2 LOCTR WRKDSECT DSECT WRKSIZE EQU *-WRKDSECT length of DSECT IHAPSA IHAASCB IHAASXB IRREVXP IEANTASM IHAACEE IKJTSB LIST=YES,EXT=YES Something I would also like to comment on and share. I saw Jon Perryman's comments. I thank him for the suggestion but still as a vendor we are the ones responsible for our code. Can it be done better, of course, but there is a way to suggest that. Over the last couple of days a customer , tried to tell us that every vendor had to have their modules identify the vendor by its first three characters of a name. There were a few other ill-educated suggestions. I understand everyone has to learn but again there is a respectful way of suggesting this to a company, i.e.; vendor. I would never try to tell a vendor, i.e.; IBM, how to code or what to do, they have suggestion forms and forums for that. Maybe I am too old school.. Regards, Scott J Ford Software Engineer http://www.identityforge.com/ aka ...somewhere lost in NJ From: John McKown john.archie.mck...@gmail.com To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Thursday, April 11, 2013 12:54 PM Subject: Re: Baseless problem He said that he did, IIRC. On Thu, Apr 11, 2013 at 10:56 AM, Steve Comstock st...@trainersfriend.com wrote: On 4/11/2013 9:33 AM, Ed Jaffe wrote: snip I wonder if the OP got his problem solved. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com/
Re: Baseless problem
Sorry if I offended anyone. That was not my intent. NEED TO was not meant to dictate what vendors must do. Only that additional considerations exist that have an impact in a product environment. I just wanted Scott to consider the following now instead of after RTM. These possible problems could be easily eliminated by placing the data first in modules. It would certainly take less time than trying to verify are not issues for your product. 1. Common abend recovery may be affected. Maybe the module eyecacther (not to be confused with load module name) and offset into that module are displayed. Maybe it expects a standard base register that starts at the beginning of the program. 2. How do customers and customer support deal with abends. Do they somehow use module base register? Do they have procedures that will be affected? Does it affect how they search the problem database? 3. How are IPCS diagnostic exec's affected? 4. Diagnostic documentation, FAQ's, problem database and other online material might have something that is affected. Are there any drawbacks to placing data first in a module? I only see possible drawbacks when it is not first. Regards, Jon Perryman. From: Martin Trübner mar...@pi-sysprog.de Enough been said about the reason and the cause (and solutions) But who dictates techniques for vendors? While your points are okay- the trick to have the definitions right at the beginning of the module (with just a J in front) is something that makes sense for everyone. If you ever tried to calculate offset in a DOB-program (data only base) from the start of the LTORG (or wherever the base points to) knows what I mean. Credit for the technique goes to Ed J.
Re: Baseless problem
Baseless for code, but you will need a base for data. I use @CODE LOCTR , @LITERAL LOCTR , LITERALSDC 0D'0' @CODE LOCTR , LARLRx,LITERALS USING LITERALS,Rx . . . . . @LITERAL LOCTR , LTORG , On Wed, 10 Apr 2013 15:06:44 -0700 Scott Ford scott_j_f...@yahoo.com wrote: :Guys, : :I am in the process of trying to understand and use baseless Assembler. I read through Ed's Jumpify Share presentation so :i am trying to read and learn...I am not asking anyone to write my code...just tell me where I am wrong .. : :SAMPL001 CSECT :SAMPL001 AMODE 31 :SAMPL001 RMODE ANY : EJECT :YREGS :PRINT OFF :SYSSTATE ARCHLVL=2 :PRINT ON :J BEGIN :DCC'cc' :DCC'' :DCC'Copyright (C), c' :DCC'All rights reserved' :BEGINDS0H :SAVE (14,12) save regs coming in :LRR12,R15 : AHI R12,CONST-BEGIN : .. : .. Failing GETMAIN for no using here :... : :CONSTDC0D :DYNAMIC DSECT :SAVEAREA DS18F register save area :PARMLIST DSF :. : LTORG , : IHAPSA : IHAASCB : IHAASXB : IRREVXP : IEANTASM : IHAACEE : IKJTSB LIST=YES,EXT=YES : END , : : 000138 0A23 201+ SVC 35 : 00013A 1B99 202 SRR9,R9 : 00013C 1B88 203 SRR8,R8 : 00013E 4100 04A4004A4 204 LAR0,DYNSIZE : 206 GETMAIN RC,LV=(0),SP=229 : 000142 208+ DS0H : 000142 209+IHB0009C DS 0H : 000142 0 210+ L 15,=AL1(B'',(0), :+ : ** ASMA307E No active USING for operand =AL1(B'',(0),(229),B'') : ** ASMA435I Record 2422 in SYS1.MACLIB(GETMAIN) on volume: SDRES1 : : :I know i misunderstood something...any pointers I would be grateful for. : :Regards, :Scott J Ford :Software Engineer :http://www.identityforge.com/ -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
Re: Baseless problem
[By the way, you set your Reply-to to yourself again, instead of to the list.] On 4/10/2013 4:06 PM, Scott Ford wrote: Guys, I am in the process of trying to understand and use baseless Assembler. I read through Ed's Jumpify Share presentation so i am trying to read and learn...I am not asking anyone to write my code...just tell me where I am wrong .. SAMPL001 CSECT SAMPL001 AMODE 31 SAMPL001 RMODE ANY EJECT EJECT. Really? YREGS PRINT OFF SYSSTATE ARCHLVL=2 PRINT ON J BEGIN DCC'cc' DCC'' DCC'Copyright (C), c' DCC'All rights reserved' BEGINDS0H SAVE (14,12) save regs coming in LRR12,R15 AHI R12,CONST-BEGIN .. .. Failing GETMAIN for no using here ... CONSTDC0D DYNAMIC DSECT SAVEAREA DS18F register save area PARMLIST DSF . LTORG , IHAPSA IHAASCB IHAASXB IRREVXP IEANTASM IHAACEE IKJTSB LIST=YES,EXT=YES END , 000138 0A23 201+ SVC 35 00013A 1B99 202 SRR9,R9 00013C 1B88 203 SRR8,R8 00013E 4100 04A4004A4 204 LAR0,DYNSIZE 206 GETMAIN RC,LV=(0),SP=229 000142 208+ DS0H 000142 209+IHB0009C DS 0H 000142 0 210+ L 15,=AL1(B'',(0), + ** ASMA307E No active USING for operand =AL1(B'',(0),(229),B'') ** ASMA435I Record 2422 in SYS1.MACLIB(GETMAIN) on volume: SDRES1 I know i misunderstood something...any pointers I would be grateful for. Regards, Scott J Ford Software Engineer http://www.identityforge.com/ Here's some fragments of code that work for me: *PROCESS COMPAT(NOCASE,MACROCASE) Ver1 sysstate archlvl=2 pgm4 csect pgm4 amode 31 pgm4 rmode 31 * * copyright (c) 2008 by Steven H. Comstock * - reentrant, baseless * * using data,12 save (14,12) save z/os's regs larl 12,data getmain r,lv=worksize st13,4(1) lr13,1 using wareas,13 . . . * at termination: * ltr 15,15 jnz err0 * lr1,13 l 0,fsize l 13,4(13) freemain r,lv=(0),a=(1) return (14,12),,rc=0 * data ds0f fsizedca(worksize) . . . * ltorg wareas dsect save ds36f'0' . . . worksize equ *-save end PGm4 -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html
Re: Baseless problem
Scott, Ditch the GETMAIN/FREEMAIN macros for STORAGE OBTAIN and STORAGE RELEASE. The former use SVCs; whereas STORAGE uses a PC. This means that STORAGE can be use in more environments than the older macros. For instance, in an SRB or when in cross memory mode (when the SYSSTATE macro is used properly). -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown
Re: Baseless problem
-Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER- l...@listserv.uga.edu] On Behalf Of Scott Ford Sent: Thursday, 11 April 2013 10:07 a.m. To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Baseless problem Guys, I am in the process of trying to understand and use baseless Assembler. I read through Ed's Jumpify Share presentation so i am trying to read and learn...I am not asking anyone to write my code...just tell me where I am wrong .. You have two problems. First, you're not setting register 12 correctly. The AHI should actually be AHI R12,CONST-SAMPL001. This is because R15 points to the beginning of your CSECT, not to BEGIN, when the program is entered. Alternatively, for clarity (and to save an instruction), you could replace both the LR and AHI with LARL R12,CONST Secondly, add a LTORG instruction after the CONST DC 0D, and add USING CONST,R12 after the AHI (or LARL). That should clear up the no active USING. Cheers, Allen SAMPL001 CSECT SAMPL001 AMODE 31 SAMPL001 RMODE ANY EJECT YREGS PRINT OFF SYSSTATE ARCHLVL=2 PRINT ON J BEGIN DCC'cc' DCC'' DCC'Copyright (C), c' DCC'All rights reserved' BEGINDS0H SAVE (14,12) save regs coming in LRR12,R15 AHI R12,CONST-BEGIN .. .. Failing GETMAIN for no using here ... CONSTDC0D DYNAMIC DSECT SAVEAREA DS18F register save area PARMLIST DSF . LTORG , IHAPSA IHAASCB IHAASXB IRREVXP IEANTASM IHAACEE IKJTSB LIST=YES,EXT=YES END , 000138 0A23 201+ SVC 35 00013A 1B99 202 SRR9,R9 00013C 1B88 203 SRR8,R8 00013E 4100 04A4004A4 204 LAR0,DYNSIZE 206 GETMAIN RC,LV=(0),SP=229 000142 208+ DS0H 000142 209+IHB0009C DS 0H 000142 0 210+ L 15,=AL1(B'',(0), + ** ASMA307E No active USING for operand =AL1(B'',(0),(229),B'') ** ASMA435I Record 2422 in SYS1.MACLIB(GETMAIN) on volume: SDRES1 I know i misunderstood something...any pointers I would be grateful for. Regards, Scott J Ford Software Engineer http://www.identityforge.com/
