Re: Poll
psIII missed a chance when setting the options for this poll. On 2019-09-16 15:45, Tony Thigpen wrote: Pop, never Poo or poop, as both sound like doing #2. Tony Thigpen Phil Smith III wrote on 9/16/19 3:50 PM: Principles of Operation-how do you refer to it? (NOT including case-let's not make this any more complicated than it is already!) 1) PofOp 2) POP 3) POO 4) Pops 5) other? Just curious-there are no wrong answers, of course! (Well, I suppose "IntelR 64 and IA-32 Architectures Software Developer Manuals" is wrong.) .phsiii -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds.—ilvi French is essentially German with messed-up pronunciation and spelling.—Robert B Wilson English is essentially French converted to 7-bit ASCII.—Christophe Pierret [for Alain LaBonté]
Re: Poll
I've always referred to it by option 2. On 2019-09-16 12:50, Phil Smith III wrote: Principles of Operation-how do you refer to it? (NOT including case-let's not make this any more complicated than it is already!) 1) PofOp 2) POP 3) POO 4) Pops 5) other? Just curious-there are no wrong answers, of course! (Well, I suppose "IntelR 64 and IA-32 Architectures Software Developer Manuals" is wrong.) .phsiii -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds.—ilvi French is essentially German with messed-up pronunciation and spelling.—Robert B Wilson English is essentially French converted to 7-bit ASCII.—Christophe Pierret [for Alain LaBonté]
Re: z15 is announced…
It wasn't there yesterday, maybe there's a day lag. Meanwhile, I remembered that it was available under NDA and I grabbed it. On 2019-09-13 08:54, Dale R. Smith wrote: On Fri, 13 Sep 2019 09:19:08 -0400, Tom Russell wrote: I'm checking every few hours for SA22-7832-12. Historically the POPs gets published on the GA date, not the announce date. So I think you can safely stop looking until 23 September 2019 which is the date in the announcement letter. The draft Redbooks are there now though. Tom Russell “Stay calm. Be brave. Wait for the signs” — Jasper FriendlyBear “… and remember to leave good news alone.” — Gracie HeavyHand I'm not sure where everybody is looking, but it's available for download on the IBM Publications Center web site: https://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?SSN=19IMP0002353716631&FNC=SRH Enter SA22-7832-12 in the Publication number field to see the current one, or enter SA22-7832 and change the number of result per page to 50 to see all available additions. For some reason, the publication dates are shown in European format, even though I have United States selected. All dates should be in Isodate format! -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds.—ilvi French is essentially German with messed-up pronunciation and spelling.—Robert B Wilson English is essentially French converted to 7-bit ASCII.—Christophe Pierret [for Alain LaBonté]
z15 is announced…
It's been quiet here, so I thought I'd 1) see if things are still alive; 2) state what we're all waiting to drop. :D I'm checking every few hours for SA22-7832-12. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds.—ilvi French is essentially German with messed-up pronunciation and spelling.—Robert B Wilson English is essentially French converted to 7-bit ASCII.—Christophe Pierret [for Alain LaBonté]
Re: New Metal C standalone product for z/OS
*sigh* Of course you notice the typo after send to a mailing list. Coincidentally, I am already giving a Metal C presentation (about converting user exits _FROM_ assembler). On 2018-07-20 11:57, M. Ray Mullins wrote: Enterprise Metal C as a Separately Priced Program Product (tm) was announced in June. The trial was announced this week (as noted). IBM Toronto will be presenting on this at SHARE in St. Louis (it's a last minute add). Coincidentally, I am already giving a Metal C presentation (about converting user exits to assembler) (being project manager has its scheduling perks ;) ). (For the record, I had no inkling of the creating of the Metal C SPPP when I came up with the idea of the presentation.) I had a great conference call yesterday with IBM Toronto Metal C folks. We are working together to cross reference our presentations. Tuesday will be Metal C day at SHARE! As much as I love assembler, I see the graying on the wall. The number of young folks interested in assembler is depressingly low. (Luckily my newest--well, only--project officer is the rare exception.) Independently, both IBM and I have concluded that there is and will be a need for maintaining and adding logic to specialized tasks. Leveraging C-language knowledge in an enterprise will help make management less gun-shy about "touching that assembler code". It's not a 100% replacement, but if it can help prevent the creep of unsuitable platforms into enterprise workload, I'm all for it. Cheers, Ray On 2018-07-17 11:02, John McKown wrote: On Tue, Jul 17, 2018 at 12:40 PM Gord Tomlin < gt.ibm.li...@actionsoftware.com> wrote: On 2018-07-17 12:45, John McKown wrote: I don't see anything in the announcement that suggests any new functionality has been added to Metal C. I think that the main push is that Metal C can be ordered as a stand alone product, separate from XLC. I would hope at a substantially reduced price. -- -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: New Metal C standalone product for z/OS
Enterprise Metal C as a Separately Priced Program Product (tm) was announced in June. The trial was announced this week (as noted). IBM Toronto will be presenting on this at SHARE in St. Louis (it's a last minute add). Coincidentally, I am already giving a Metal C presentation (about converting user exits to assembler) (being project manager has its scheduling perks ;) ). (For the record, I had no inkling of the creating of the Metal C SPPP when I came up with the idea of the presentation.) I had a great conference call yesterday with IBM Toronto Metal C folks. We are working together to cross reference our presentations. Tuesday will be Metal C day at SHARE! As much as I love assembler, I see the graying on the wall. The number of young folks interested in assembler is depressingly low. (Luckily my newest--well, only--project officer is the rare exception.) Independently, both IBM and I have concluded that there is and will be a need for maintaining and adding logic to specialized tasks. Leveraging C-language knowledge in an enterprise will help make management less gun-shy about "touching that assembler code". It's not a 100% replacement, but if it can help prevent the creep of unsuitable platforms into enterprise workload, I'm all for it. Cheers, Ray On 2018-07-17 11:02, John McKown wrote: On Tue, Jul 17, 2018 at 12:40 PM Gord Tomlin < gt.ibm.li...@actionsoftware.com> wrote: On 2018-07-17 12:45, John McKown wrote: I don't see anything in the announcement that suggests any new functionality has been added to Metal C. I think that the main push is that Metal C can be ordered as a stand alone product, separate from XLC. I would hope at a substantially reduced price. -- -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: New Metal C standalone product for z/OS
One thing to remember about CDSECT is that it's reading ADATA, and conditionals tailor what's in there, just like the assembled source. I've been playing with it lately for a SHARE presentation (hint), and I've become very familiar with its output and idiosyncrasies. On 2018-07-18 16:22, Charles Mills wrote: Hmmm. I have not encountered that as a limitation. CDSECT is not a macro (in the HLASM sense) converter; it is a DSECT converter. If you had some sort of a multi-platform HLASM macro (z/OS and VSE? 31- and 64-bit? MVS and z/OS?) it would be lovely to think it would generate a corresponding multi-platform header with ifdef's for AIF's but it does not. I guess it would make sense, but it does not do that. You would indeed have to generate two structs and ifdef between them. It generates pretty much vanilla C. If you had two platforms that both needed headers corresponding to a Z DSECT I suspect its output could be made to work for both. In fact, I am that audience: I generate headers and use them in "production" on z/OS; and for compilation and very-alpha testing on Visual Studio. The only tweaking I have had to do is with the syntax of #pragma pack: it generates pack(packed)/pack(reset) and Visual Studio wants pack(push)/pack(1)/pack(pop). It is not a perfect "automated" tool. I would not expect to push 100 DSECTs through CDSECT and have all 100 be usable without manual intervention. But it's a darned sight easier and more accurate than hand conversion. Believe me -- I have tried. One thing CDSECT does not attempt to do itself is naming. It would take some cleverness on the user's part to create a job or script that would push a PDS with members MYMACRO1, MYMACRO2, etc. through CDSECT and come out automatically with mymacro1.h, mymacro2.h, etc. I always do them one at a time. My output is always named MYUSRID.CDSECT and I manually copy that and rename it to whatever.h. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, July 18, 2018 3:33 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: New Metal C standalone product for z/OS On 2018-07-18, at 16:24:33, Charles Mills wrote: CDSECT cares only about assembled code and labels. I believe conditional assembly instructions are ignored (but not their effect, of course -- it's usual input is an assembled macro such as DCBD). CDSECT does not to my knowledge generate #ifdefs. I think #pragma packed() is its only C macro output. Given the intense use that both C and Assembler make of conditional compilation to support multiple target environments, this is an onerous limitation. I'm imagining assembling a DSECT for each target; running CDSECT for each, then concatenating the outputs separated by #ifdef ... #endif. Hmmm... Doesn't diff(1) have the ability to generate such #ifdefs? -- gil -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Two string instruction questions
Very late to the game, but could you use one of the new vector string instructions? Possibly a combination of VECTOR FIND ELEMENT EQUAL and VECTOR STRING RANGE COMPARE. I've done nothing with this (yet), so I can't provide any answers or advice. You would have to be z13 or better to open. On 2018-03-14 08:51, Charles Mills wrote: 1. Is there a machine instruction that will find one string within another? That given "Now is the time" and "is" would find the "is" and return a pointer to it? A machine instruction analog of Rexx POS? 2. Searching the PoOp for such an instruction led me to CUSE. It does not seem that CUSE could be used for this - is that correct? If I am reading CUSE correctly, then given "Now is the time", "All is well" and 2 or 3 would return the position of "is". Is my reading correct? What would that be good for? What would be a reasonable real-world use? Thanks, Charles -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Very sad news
It is with deep sadness that I must convey this news. Tineke Graafland-Ehrman has announced that Dr. John Ehrman, to whom we owe so much for our love of IBM mainframe assembler, passed away within the past day. John will be cremated, and there will be a memorial service in Palo Alto in the future. SHARE is working on posting a memorial page. which is why I felt it was OK to pass along the news. If you were not aware, SHARE created an award, The John R. Ehrman Award for Sustained Excellence in Technical Education, to honor him. The first award is scheduled to be given at SHARE 130 in Sacramento. Godspeed, John. May there always be plenty of resources to assemble and run your code. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Save areas (not XPLINK).
I did run into F2SA over 10 years ago. I was looking at a dump that occurred when a product I worked on called Unicode services (it turned out to be an actual bug in the service). The fine gentleman Peter Relson answered my IBM-MAIN query here, along with a caveat that some components do not use publicly documented save area interfaces. https://listserv.ua.edu/cgi-bin/wa?A2=IBM-MAIN;88eeea77.0609 As I was On 2017-05-30 07:31, Steve Smith wrote: First answer: The high-halves portion of the save areas is used by the caller, not the callee. I suppose for the case when calling a program that doesn't save all 64 bits, yet uses some of them. The Assembler Services guide goes into great detail on linkage conventions and save area formats, but it requires some close reading. I see F0*, F1, F4, F5, F6, F7, & F8. I could guess what F2 & F3 were, but I've never seen documentation for them. *aka classic 72-byte savearea. sas On Tue, May 30, 2017 at 10:11 AM, Gary Weinhold wrote: I have notes that indicate there can be an F1SA, which means that this savearea may be only 8 bytes long because the hardware linkage stack was used. If R13 is non-zero, the F1SA savearea is a standard 72-byte save-area. F6SA is supposed to mean the hardware linkage stack was used and the savearea is 144 bytes. Since it is the called program that has to save all the registers, I think the answer to question 2 could only be that the alet of previous savearea is the value in AR13 at entry. Regarding question 3: Do you have any control over what languages are calling you? I haven't come across any standard LE-supported languages using anything but the historic 72-byte format, but there may be announcements I've missed. I figured these other save areas may be documented for vendor software so that debugging software would be able to forward and backward chain saveareas with some degree of confidence. My notes for F8SA are different (question 1) so I can't comment. I think my notes came from a Tom Conway article or presentation. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone: +1.613.523.5500 x216 Email: weinh...@dkl.com<mailto:weinh...@dkl.com> [http://www.dkl.com/wp-content/uploads/2015/07/dkl_logo.png]< http://www.dkl.com/> Visit us online at www.DKL.com<http://www.dkl.com/> [http://www.dkl.com/wp-content/uploads/2015/08/banner.png] E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. __ On 2017-05-30 09:39, John McKown wrote: As best as I can tell, there are 5 different Save Area formats. There is the historic 72 byte format. This saves bits 32..63 of GPR 14-12. There is an F4SA which is 144 bytes and contains bits 0..63 of GPRs 14-12. There is a F5SA which holds bits 0..63 of the GPRs 14-12 and bits 0..31 of GPRs 0-15. There is F7SA which holds bits 0..63 of GPRs 14-12 and ARs 14-12 plus "alet of previous save area" (isn't this just AR13 at entry?). And finally, there is F8SA which is bits 0..63 of GPRs 14-12, ARs 14-12, "alet of previous savearea", bits 32..63 of GPRs 0-15. ref: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com .ibm.zos.v2r2.iead200/iead200571.htm First question: Why save the "high word" of regs 0-15 in addition to the entire double word of regs 14-12 (all but GPR15)? Second question: Why say "alet of previous savearea" rather than AR13? Is there a case where this is _not_ in AR13 at entry? If so, how would I know? Philosophy question: If I am writing a non-LE enabled HLASM subroutine, should I check the "save area type" to ensure that my routine is properly callable from any non-XPLINK routine? I know that the standard says that it is the _caller's_ responsibility to do this. But I'm paranoid. And I don't way to ASSuME that the caller is paying attention and by so doing possibly introduce a memory overlay in the caller. Also, if I get a "bad" type of savearea, should I "do something", such as using the linkage stack, or should I abend or maybe return a "failed" return code? -- M. Ray Mullins Roseville, CA, USA German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Structured programminng macros
I've been working off and on creating a REDO macro to pair with ITERATE (like DOEXIT/ASMLEAVE). I'm very close to getting it working; alas, the spare time has been non-existent for months. If I get some cycles in the near future, I'll go back to work on it. I'm having a problem with following SPMs generating wrong branches; I know it's a nesting issue, it's just trying to track down where an index is (or not) being modified when it should not (or be). On 2017-05-15 04:46, Pieter Wiid wrote: On 15/05/2017 13:42, Robin Vowels wrote: From: "Pieter Wiid" Sent: Monday, May 15, 2017 6:36 PM Branch to iterate is what I would LIKE. You could try a BCT, or BXLE etc instruction. There is not such structure as the moment. If nobody else wants to play with it, I will try to work on it when done with my current upgrade cycle. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus Again, I would like to see an ITERATE_IF, similar to the DOEXIT. Thus, I would have ITERATE_IF , instead of IF ITERATE ENDIF The BXLE / BCT / JCT / JXLE are all catered for by the DO FROM constructs. -- M. Ray Mullins Roseville, CA, USA German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: My assembler text v2.00
Adding to the thanks. We appreciate all your hard work and dedication to HLASM, and we hope to see you not only here but at SHARE Winter 2017. On 04/13/2016 16:42, John Ehrman wrote: The second edition of my Assembler Language textbook is available for download at http://idcp.marist.edu/enterprisesystemseducation/assemblerlanguageresources-1.html The text is a PDF file (it's big: 1346 pages). The simple conversion and I/O macros decscribed in Appendix B are also available there. I'll be retiring from IBM at the end of May, so if you have any comments or suggestions, please send them to me at johnehrm...@gmail.com . Since the text was created on z/VM using IBM's BookMaster, I doubt I'll be able to create any further versions after retiring. I may, however, be able to provde occasional supplements and errata through the Marist College web site. (I'd like to provide a second text describing the Conditional Assembly and Macro language, but that will depend on time, energy, and need.) I plan to be available for consulting on Assembler Language topics like education, modernization, and simplification. Regards... John - 555 Bailey Ave, San Jose CA 95141 USA +1-408-463-3543 ehr...@us.ibm.com -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Assembler exercise - MAX of two or more equates
Arrgh, not enough coffee. Change "macros" to "techniques". On 06/30/2015 08:07, M. Ray Mullins wrote: Catching up on ASSEMBLER-LIST… Where are those macros? I did come across a need for a MAX-style function which I solved using other means, but I love learning new techniques. Thanks, Ray On 06/22/2015 07:26, Ed Jaffe wrote: On 6/17/2015 2:55 PM, David Cole wrote: Excellent! Just stuff that into an ignorable dsect, and there you go! I never thought of this method. Very creative. We use the same basic technique in a robust set of macro-based math functions to to ensure one EQU is greater or less than another, to ensure a set of EQU values are all equal, to compute the max/min of the set, etc. Such functions come in quite handy... -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Assembler exercise - MAX of two or more equates
Catching up on ASSEMBLER-LIST… Where are those macros? I did come across a need for a MAX-style function which I solved using other means, but I love learning new techniques. Thanks, Ray On 06/22/2015 07:26, Ed Jaffe wrote: On 6/17/2015 2:55 PM, David Cole wrote: Excellent! Just stuff that into an ignorable dsect, and there you go! I never thought of this method. Very creative. We use the same basic technique in a robust set of macro-based math functions to to ensure one EQU is greater or less than another, to ensure a set of EQU values are all equal, to compute the max/min of the set, etc. Such functions come in quite handy... -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: 8 character mnemonics
Of course, it would have helped if I'd provided an actual example of something longer than 8. SELECT -> ASM_SELECT. :) On 2015-01-22 10:05, M. Ray Mullins wrote: The HLASMTK SPMs have been doing this for years. Macros like IF are OPSYNed to ASM_IF, and the source for ASM_IF is in the copy member. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] On 2015-01-22 05:54, Tony Thigpen wrote: I have used longer-than-8 macros for many years. Works great. I have one source macro that I include at the top of the member that is just 8 characters long. Inside, it has many macro 'redefs' so that I can use a long macro name in the code, but it gets converted to a shorter 8 character macro before going out to the library to get the macro. A short example: MACRO &NAMEPERFORM_ON &ADDR,&BAD_VALUE= &NAMEPERFORMO &ADDR,BAD_VALUE=&BAD_VALUE MEND Then, in my code, I use the longer PERFORM_ON. Some of my macro names are quite long, like: GET_FIRST_IN_CHAIN ADD_END_OFF_CHAIN FIND_IN_CHAIN Tony Thigpen John Ehrman wrote on 01/21/2015 02:02 PM: Dave Cole noted again... <> I think HLASM has supported operation field entries longer than 8 characters for a long time, but resolution was possible only to source macros. (No, I haven't tried it.) John Ehrman -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: 8 character mnemonics
The HLASMTK SPMs have been doing this for years. Macros like IF are OPSYNed to ASM_IF, and the source for ASM_IF is in the copy member. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] On 2015-01-22 05:54, Tony Thigpen wrote: I have used longer-than-8 macros for many years. Works great. I have one source macro that I include at the top of the member that is just 8 characters long. Inside, it has many macro 'redefs' so that I can use a long macro name in the code, but it gets converted to a shorter 8 character macro before going out to the library to get the macro. A short example: MACRO &NAMEPERFORM_ON &ADDR,&BAD_VALUE= &NAMEPERFORMO &ADDR,BAD_VALUE=&BAD_VALUE MEND Then, in my code, I use the longer PERFORM_ON. Some of my macro names are quite long, like: GET_FIRST_IN_CHAIN ADD_END_OFF_CHAIN FIND_IN_CHAIN Tony Thigpen John Ehrman wrote on 01/21/2015 02:02 PM: Dave Cole noted again... <> I think HLASM has supported operation field entries longer than 8 characters for a long time, but resolution was possible only to source macros. (No, I haven't tried it.) John Ehrman -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Defunct? (Was: ASSEMBLER-LIST Digest)
On 2014-10-01 07:36, mar...@pi-sysprog.de wrote: No. But it sure is missing the like button Or +1, or Pin to Pinterest, or share to YouTube or Tumblr… -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.z390.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: MHELP bug?
And…I'm replying to myself. Found a possible instigator. If the macro is being pulled out of the library, then the BRANCH entries do not show up. But COPY it into your program, and they do show up. Again, if anyone is bored at SHARE…:) On 2014-03-11 09:00, Ray Mullins wrote: It gets better. I've encountered an instance where specifying a pure decimal term also does not issue the ++//MHELP BRANCH lines. *sigh* PMR time. On 2014-03-06 14:44, David P de Jongh wrote: I misread your post - trying again with X'3F' vs 63, results are identical, but there are no ++//MHELP BRANCH lines, only ++//MHELP CALL, along with a whole lot of //MHELP AIF lines. On 03/06/14, David P de Jongh wrote: The manual says: /options/ is the sum of the binary or decimal options described below. _MHELP_ _B'1'_ _or_ _MHELP_ _1,_ etc... MHELP B'0001' works (produces a nested macro trace) MHELP B'1' also works, as does MHELP 1. But - MHELP X'01' and MHELP X'37' do both work. Though I don't have time to examine the X'37' results microscopically, there are lots of them. This is with HLASM R5 on z/OS 1.13 David de Jongh On 03/06/14, Ray Mullins wrote: Hi everyone, Since it's gotten somewhat quiet (and it's past hump day, so the camel case thread is no longer relevant :) ), I'm looking for confirmation that I've discovered an MHELP bug. I'm seeing that if I use an operand that is not decimal digits, i.e., a T' on the operand would not return 'N', branch trace (bit B'0010') is ignored. I've tested X'..', B'..', and EQUs. If you are bored and would like to try this, it's simple to recreate. Just wrap one macro invocation with MHELP 63/MHELP 0, and another with MHELP X'3F'/MHELP 0. In the latter I'm not seeing any MHELP BRANCH entries, as if I specified MHELP 61 (B'0001'). I do see MHELP CALL entries, so that rules out entries prefixed with ++//MHELP. I'm at z/OS 1.13 PTF UK96299. Cheers, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: MHELP bug?
It gets better. I've encountered an instance where specifying a pure decimal term also does not issue the ++//MHELP BRANCH lines. *sigh* PMR time. On 2014-03-06 14:44, David P de Jongh wrote: I misread your post - trying again with X'3F' vs 63, results are identical, but there are no ++//MHELP BRANCH lines, only ++//MHELP CALL, along with a whole lot of //MHELP AIF lines. On 03/06/14, David P de Jongh wrote: The manual says: /options/ is the sum of the binary or decimal options described below. _MHELP_ _B'1'_ _or_ _MHELP_ _1,_ etc... MHELP B'0001' works (produces a nested macro trace) MHELP B'1' also works, as does MHELP 1. But - MHELP X'01' and MHELP X'37' do both work. Though I don't have time to examine the X'37' results microscopically, there are lots of them. This is with HLASM R5 on z/OS 1.13 David de Jongh On 03/06/14, Ray Mullins wrote: Hi everyone, Since it's gotten somewhat quiet (and it's past hump day, so the camel case thread is no longer relevant :) ), I'm looking for confirmation that I've discovered an MHELP bug. I'm seeing that if I use an operand that is not decimal digits, i.e., a T' on the operand would not return 'N', branch trace (bit B'0010') is ignored. I've tested X'..', B'..', and EQUs. If you are bored and would like to try this, it's simple to recreate. Just wrap one macro invocation with MHELP 63/MHELP 0, and another with MHELP X'3F'/MHELP 0. In the latter I'm not seeing any MHELP BRANCH entries, as if I specified MHELP 61 (B'0001'). I do see MHELP CALL entries, so that rules out entries prefixed with ++//MHELP. I'm at z/OS 1.13 PTF UK96299. Cheers, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
MHELP bug?
Hi everyone, Since it's gotten somewhat quiet (and it's past hump day, so the camel case thread is no longer relevant :) ), I'm looking for confirmation that I've discovered an MHELP bug. I'm seeing that if I use an operand that is not decimal digits, i.e., a T' on the operand would not return 'N', branch trace (bit B'0010') is ignored. I've tested X'..', B'..', and EQUs. If you are bored and would like to try this, it's simple to recreate. Just wrap one macro invocation with MHELP 63/MHELP 0, and another with MHELP X'3F'/MHELP 0. In the latter I'm not seeing any MHELP BRANCH entries, as if I specified MHELP 61 (B'0001'). I do see MHELP CALL entries, so that rules out entries prefixed with ++//MHELP. I'm at z/OS 1.13 PTF UK96299. Cheers, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: CamelCase
Der Gebrauch des Majuskeln ist ein weiterer Anlass, warum ich meine, dass unsere Deutschesprachefreunde haben eine bessere Idee. (Yeah, the middle of that sentence might have an issue or two.) On 2014-03-03 11:36, Ed Jaffe wrote: On 3/3/2014 11:24 AM, Tony Thigpen wrote: All my COBOL courses teach writing code in mixed case. Often I find customers who tell me the shop standard is still all uppercase. When I use the "all uppercase makes feel like I'm shouting" line, I often get back "lowercase is like whispering". LOL. Never heard that one until now. :) Of course, quips - no matter how clever - don't refute studies. Citing them might be useful... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: CamelCase Field Names (Was: Re: HLASM continuation...)
On 2014-02-22 12:09, Paul Gilmartin wrote: On 2014-02-22, at 12:54, Peter Relson wrote: Changing this by default or en masse is unlikely to happen. Changing individual macros (in a forthcoming release) is much more feasible, and if you have favorite "candidates", let me know and I will pass that along to the developer for their consideration. Do you appreciate how much happier the customer base would be if the PL/x compiler were to be made a product? Customer and IBM developers could be reading from the same page, and IBM could be spared the dual maintenance of source. It has been decades since IBM had a competitive advantage to defend by keeping PL/x intramural. It was a product at one time! It was made available back in (I think) the late 1990s, although it was targeted at ISVs. But the response from ISVs was thunderous crickets, and after a while it was withdrawn. IIRC there were a couple of ISVs who took it on. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: DC CA'[]'
*sigh* All this talk about CP 037 and 1047. They're obsolete. The proper CPs to use today are 1140 and 924. Off the top of my head, quite a few contributors to this can tell us why; my good friend Herr Trübner is one who comes to mind immediately, although he might say that CP 1141 should be used intead of 273, and our Hursley friends might vouch for 1147 versus 285. I like 1148, personally, replacing 500. You see 500/1148 a lot in WMQ. On 2014-01-15 00:43, Jonathan Scott wrote: Ref: Your note of Tue, 14 Jan 2014 14:55:55 -0700 Constants with type CA are currently translated from EBCDIC codepage 037 to the 7-bit displayable ASCII codes hex 20 through 7E, not to code page 819. Anything which does not translate to a valid ASCII character in that range is left untranslated. (The 7E tilde character was missing until quite recently, which I spotted and fixed when testing the changes for PM75317, which was mainly to ensure that the HLASM source code could be stored in a UTF-8 repository if necessary). I do not know why this scheme was chosen historically. It does seem rather US-centric to me. The ASMALTAS table used for TRANSLATE(AS) converts code page 037 to code page 819 (ISO 8859-1), using a full 256-byte mapping. Jonathan Scott -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: C calling 24bit assembler
What type of I/O? VSAM I/O can have everything above the line, including ACBs. The only below-the-line restriction since *mumbles some long past version of MVS* for non-VSAM is the DCB itself. Buffers can be placed above the line if you use a DCBE with RMODE31=BUFF and associated it with the DCB. OPENs and CLOSEs use the MODE=31 keyword to generate the SVC parm list for executing AMODE 31. What you have to do is obtain storage below the line for your DCBs and build them manually, usually by having model DCBs in your source and moving them into the below-the-line storage. Get familiar with the DCBD macro, the mapping macro for the DCB, because you will have to probably have to store the DCBE address manually into the DCB. (You mention threads, and that implies reentrant code (for the most part)). There are some other things you should be aware of since you are doing multitasking/threading. You may want to consider translating the assembler routines into equivalent C run-time library calls, if possible. This can make sharing of I/O much easier when multiple threads could be writing to the same ACB or DCB (FILE in C-speak). There are routines for both VSAM and non-VSAM. Also, I believe Enterprise COBOL does have some multitasking capability or it came in with the 5.1 compiler. I am not familiar with it, though, just like I am not familiar with OO COBOL. :) On 2013-11-04 10:23, Scott Ford wrote: Guys: I am in the process of rewriting a STC from single thread Cobol into threaded C. I have some Assembler routines that perform disk I/O , so I assume they are doing I/O below 'the line'. Can someone point me the direction how I can modify the Assembler routines to perform I/O above the line ? -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: which instructions should I use?
On 2012-08-29 11:42, Edward Jaffe wrote: On 8/29/2012 11:07 AM, John Ehrman wrote: But be careful: I've seen many examples of poor coding practices that -- simply because they were familar -- were propagated from one program to another, to the detriment of all. When I worked for a large bank in the 1980s, and saw how "new" JCL was constructed there, I conjectured that all batch JCL is descended from the same singular job stream. There's an old joke that Adm. Grace Hopper wrote the first COBOL program, and every COBOL program since is a derivative. But there are kernels of truth in such jocularity, as even today I start brand-new assembler code by copying a skeleton with the entry/exit/work area macros. Side humour: My T-bird spelling check wants to correct "Jaffe" to "Gaffe". -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: length of DSECT
On 2012-08-06 11:48, John Ehrman wrote: Worth considering; added to the HLASM "Wish List". While we're at it, if it's not too much trouble (there's the escape clause), the length attribute for any xSECT would be a nice touch. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: HLASM - 20 years old
On 2012-06-21 07:36, Sharuff Morsa3 wrote: Happy Birthday HLASM. I met Dr. John several years ago when I interviewed at Santa Teresa Labs for a DB2 Federation product. I sent him an email asking if I could meet him after my interview was over, and he gladly accepted. He gave me the quick tour of the machine room (the largest I had ever seen), and we spent a few minutes chatting about HLASM, assembler, and all sorts of z/Architecture tech-type subjects. I consider myself lucky that I was able to meet him in person. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Checking for "more restrictive" TYPECHECK(REGISTER) at assemble time
On 2012-06-19 10:44, John Ehrman wrote: The SYSATTRA internal function can retrieve the Assembler Type assigned by an EQU,and the value is independent of the EQUated symbol (so you don't have to parse special names). Might that be useful? John Ehrman That's actually what I'm doing now. :) I was hoping to create logic that didn't require setting of the 5th EQU parameter. Maybe I'll add check logic and insure that any register EQU used as a parameter has the 5th parameter coded, and if not, fire off a nasty MNOTE. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Checking for "more restrictive" TYPECHECK(REGISTER) at assemble time
LLH comes in at MACHINE(ZS-3), so the macro substitutes for LLH if assembled with MACHINE(ZS-2) and earlier. (O' is a nice addition.) I'm using a combination of LH and IILH (not IILL, as I wrote) to properly reflect the operation of LLH. LH wants GR32, IILH wants GR64. I'm working around that if the first operand is one of our register equates, but if someone slips something like LLH MYREG,ASCBASID where MYREG is tagged as GR, or not tagged at all, and "more restrictive" is not in effect, I'd like to bypass the code that gets the proper GR32 and GR64 EQUs. If "more restrictive" is in effect and they're using GR for their own equate, then screw 'em, let them deal with the ASMA323Ws. :) It's not a life-or-death situation. Let me just say that in what we've currently got now in our macro set, it would be nice to know when HLASM is in "more restrictive" mode. On 2012-06-19 09:57, McKown, John wrote: I'm not entirely sure exactly what you want. But one thing that I do is use the Assembler parm MACHINE(architecture) to indicate my "highest level" instruction set. E.g. I use "//ASM EXEC PGM=ASMA90,PARM='MACHINE(ZSERIES-3)' to cause an assembler error if I were to use EXRL other instruction which would abend with an S0C1 on my z9BC. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asmi1020/A.2.30 Or is it that you want some macros to use which would expand to an LLH, if at the proper minimal MACHINE level, or to a "equivalent" set of "lower MACHINE level" instructions? If you want to test this, look at&SYSOPT_OPTABLE at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/asmr1020/7.10.28 I don't understand the comments about LLH. Is is LLH vs. LLGH? And you want, somehow, to determine which to use? LLH should use GR32 equates and LLGH should use GR64 equates. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 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® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ray Mullins Sent: Tuesday, June 19, 2012 11:29 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Checking for "more restrictive" TYPECHECK(REGISTER) at assemble time Hi everyone, I've been through the Fine Manual and the list archives, and according to my perusal this is not possible, but I'll throw it out there to the brain trust that is ASSEMBLER-LIST. I'm working on some instruction substitution macros to catch any slips of instructions like LLH into code that for one reason or another has to be assembled with MACHINE(ZS-2), as well as better MACHINEs. In one program, we are experimenting with TYPECHECK(REGISTER) by coding two sets of equates, one GR32 and one GR64. Our one hitch is that one of these macros - specifically one for LLH, uses one instruction that wants GR32 and one instruction that wants GR64. (I can see why instructions like IILL want GR64 - I may not agree with it, but I can see the premise.) Our basic register equates are defined such that I can determine the GR32 and GR64 equates from the register supplied. However, it would helpful to know if HLASM has gone into its "more restrictive" type checking (their words from Appendix N from the Programmer's Guide) to add this extra processing, or, if not, don't bother. There's no nice &SYSOPT_ flag for TYPECHECK, nor one saying "more restrictive" has kicked in. I realize that this may be difficult, nigh impossible, depending on where in the assembly process that "more restrictive" kicks in. To handle any register equates that don't conform to our naming standard (something like CBBASE EQU R10), the oft-requested ability to SETA to an EQU value inside a macro would be wonderful. But I'm not holding my breath on that one. Short of putting in a formal enhancement request for a &SYSOPT_ or other flag (or one for TYPECHECK and one for "more restrictive" checking), or waving at Sharuff and asking if he thinks this is a good idea, does anyone have any ideas? Cheers, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far ca
Checking for "more restrictive" TYPECHECK(REGISTER) at assemble time
Hi everyone, I've been through the Fine Manual and the list archives, and according to my perusal this is not possible, but I'll throw it out there to the brain trust that is ASSEMBLER-LIST. I'm working on some instruction substitution macros to catch any slips of instructions like LLH into code that for one reason or another has to be assembled with MACHINE(ZS-2), as well as better MACHINEs. In one program, we are experimenting with TYPECHECK(REGISTER) by coding two sets of equates, one GR32 and one GR64. Our one hitch is that one of these macros - specifically one for LLH, uses one instruction that wants GR32 and one instruction that wants GR64. (I can see why instructions like IILL want GR64 - I may not agree with it, but I can see the premise.) Our basic register equates are defined such that I can determine the GR32 and GR64 equates from the register supplied. However, it would helpful to know if HLASM has gone into its "more restrictive" type checking (their words from Appendix N from the Programmer's Guide) to add this extra processing, or, if not, don't bother. There's no nice &SYSOPT_ flag for TYPECHECK, nor one saying "more restrictive" has kicked in. I realize that this may be difficult, nigh impossible, depending on where in the assembly process that "more restrictive" kicks in. To handle any register equates that don't conform to our naming standard (something like CBBASE EQU R10), the oft-requested ability to SETA to an EQU value inside a macro would be wonderful. But I'm not holding my breath on that one. Short of putting in a formal enhancement request for a &SYSOPT_ or other flag (or one for TYPECHECK and one for "more restrictive" checking), or waving at Sharuff and asking if he thinks this is a good idea, does anyone have any ideas? Cheers, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: DS 0H
On 2012-06-13 10:21, Pesce, Andy wrote: I was always taught: LABELEQU* to distinguish a label. However, when I perform maintenance on a program that someone else wrote with: LABELDS 0H I use that way. This keeps it standardized throughout the program as not to confuse the next person that does maintenance. The second biggest problem with EQU * (after the possible branch issues) is that if you use TEST (whether for TSO or z/XDC), no SYM card is generated for an EQU, but one is for a DS/DC 0H. This continues today with ADATA. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: DS 0H
On 2012-06-14 10:41, Tom Marchant wrote: On Thu, 14 Jun 2012 13:19:37 -0400, J R wrote: The whole point of such a construct would be to provide an elegant alternative to the somewhat awkward "DS 0H" and FSVO "elegant" and "awkward". And haven't we all switched to DC 0H by now in code for the binder benefits? -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: MVC with 2nd operand length
On 2012-05-23 16:42, John Ehrman wrote: Paul Gilmartin asked: So, I wonder: If I code: MVC X+OFFSET,=C'string' is the implied length as: MVC X+OFFSET(L'X),=C'string'<-- This one! or: MVC X+OFFSET(L'X-OFFSET),=C'string' Implied lengths are always taken from the first term in the operand. Thus, the implied length of (X+1) is L'X, while the implied length of (1+X) is L'1, or 1. This is a feature I use often when building variable WTO texts and using EQUates for the relative positions into the TEXT= work area. Stick the length in the second operand, something like this incredibly snipped example with stuff not necessarily in the order where I'd code it (professionals at work, do not attempt this at home, too lazy to invoke fixed-width fonts, yeah I'm coding this off the top of my head so there are better ways but I 'm trying to explain the principle...): WTOTEXT DSAL2,CL119in a DSECT MSG0001I DCAL2(L'MSG0001IT) MSG0001IT DC C'Job produced this name' MSG0001I_JOBN EQU 2+4,L'TIOCNJOB,C'C' MVC WTOTEXT(2+L'MSG0001IT),MSG0001I MVC MSG0001I_JOBN+WTOTEXT,TIOCNJOB The above can be tweaked with the MVC2 stuff to make it even better, but it's past 5... -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: MVC with 2nd operand length
Try using the HLASMTK SPM SELECT on a CLC where a variable-length literal is the first operand. A CLC:2 or CLC2 macro or whatever would use the length of the second operand would simplify a lot of code that I have inherited. Cheers, Ray On 2012-05-23 11:24, Tony Thigpen wrote: I am actually looking at a TCP buffer to decide what function is being executed. There is stuff in the COMMAND (which can be 64k) field after the blank so we can't stretch the second operand. The length used must be the length of the =C'' field This is just a short sample. I have some programs that have to check for many more commands and branch accordingly. (I did leave out the BE's in my sample since I figured everyone would understand that.) Right now, I use the first format, with the =C'' first, but it be much more handy to use the second format with the =C'' last. FYI, The 'how' is not as important to me as the ability. The 'CLC:2' just seems to be the best suggestion right now. Although, I would not have minded something like: CLC COMMAND(#),=C'OPEN ' Tony Thigpen -Original Message - From: Rob van der Heij Sent: 05/23/2012 11:51 AM On Wed, May 23, 2012 at 3:51 PM, Tony Thigpen wrote: Switch CLC operands works, but leaves the code messier. CLC =C'OPEN ',COMMAND CLC =C'CLOSE ',COMMAND CLC =C'TERMINATE ',COMMAND CLC =C'END ',COMMAND vs: CLC:2 COMMAND,=C'OPEN ' CLC:2 COMMAND,=C'CLOSE ' CLC:2 COMMAND,=C'TERMINATE ' CLC:2 COMMAND,=C'END ' Think you stretch it beyond where it breaks. You would not have the CLC's without intervening tests on the CC so it does not look really so bad... And I am fairly sure you normally would not want to CLC the long field with a random section of the literal pool starting at C'OPEN' :-( What I would want is CLC:2 to "stretch" the literals to the length of the field, rather than having me to code it like CLC COMMAND,=CL(L'COMMAND)'OPEN' Rob -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: MVC with 2nd operand length
On 2012-05-16 12:39, John Ehrman wrote: "Retired mainframer" noted: I must be missing something obvious. Why not simply MACRO &LabMVC2&Target,&Source &LabMVC&Target(L'&Source-1),&Source MEND or avoid the macro completely with &Lab MVC Label1(L'Label2-1),Label2 The reason for the more complex macro is that the source operand may have been encountered by the assembler for the first time in the MVC instruction, and not yet appear in the symbol table with all attributes assigned (particularly, length), so the L' reference might fail. (This can happen easily with literal operands.) The purpose of the LA instruction in the macro is to force the&Source operand into the symbol table in case it's not there already. See? I've been dealing with IBM assembler for over 3 decades, and HLASM since its initial publication. And there is still much for me to learn! Thanks for this tip, John! -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: ADATA Exit
On 2012-04-19 12:06, Martin Truebner wrote: Ray, I assume you tried // ASSGN SYSADAT,IGN? No i did not- Why would you expect VSE to know something about that special number ADAT? But I did try // DLBL +EXTENT (pointing to SYS010) and assgn SYS010 IGN- This did not work (and this never worked except for very old COBOL-programs that had logic build into them to honor it). It was worth a shot. :) You could try DLBLing a "dummy" 1-track SAM-ESDS file. As long as I do not specify an exit it does produce data. Now that sounds like a bug. I vote for firing up the HLASM Debug Tool (which I must correct myself - I used it rather than the IBM Debug Tool (for LE-based languages) back in my prior life). Or, possibly, another debugging tool that I think you are familiar with. :D I have used ADATA in the past under VSE; I created VSAM files that It works with regular SAM as well. I used VSAM because I didn't need to deal with EXTENTs. :) -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: ADATA Exit
On 2012-04-19 06:37, Martin Truebner wrote: I am writing an ADATA Exit for HLASM I told the invoker (ASMA90) all possible Return-code/reason code combinations (that is 4/0 4/4 4/8), because I want to write the records in my format. All I get is a one line nastygram: ** ASMA418C Unable to open ADATA file Question 1: anyone succeeded in convincing the Assembler not to attempt open of the ADATA file - any op-sys. Yes. I have used the sample exit for converting HLASM V5+ to HLASM V4 to use with the long-neglected Program Understanding Tool, under z/OS. Question 2: I am on VSE and I do not understand this sentence (in Programmers Guide- chapter on ADATA exit processing): - Suppress the associated data output by doing this: -z/OS (okay I got this) -CMS Issue (okay I do understand this as well) -z/VSE Assign SYSADAT to IGN. The last sentence is something I have problems doing. I assume you tried // ASSGN SYSADAT,IGN? Judging from the Programmer's Guide, this is supported. But I agree, that seems strange; I've never known of a SYSADAT logical unit. There are only three hits in the z/VSE documentation for SYSADAT: in messages and codes for the ASMA418C, and two in the area of the C DSECT conversion tool. These all reference DLBL. You could try DLBLing a "dummy" 1-track SAM-ESDS file. I have used ADATA in the past under VSE; I created VSAM files that were then fed into the appropriate utility for use in the IBM Debug Tool (since, despite my begging over the years, Dave Cole still hasn't ported z/XDC to z/VSE. (Yes, this is a joke. There are very good economic reasons why Dave has not done it. :) )) -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Macro compound symbols
Hello Chuck, Parameters on the macro prototype are not assembler variables. They have quirks in processing, and you've discovered one of them. To do what you want to do, you will have to SETx the parameters to assembler variables, and then perform your compound variable logic. Cheers, Ray On 2012-04-01 10:07, Hardee, Chuck wrote: Hello, Thru the IBM Mainframe list I have been able to get the assembler to accept the following as valid: &VARNAM SETC 'P'.'&I' &XVAL SETC '&(&VARNAM)' &XVAL is defined as LCLC This statement: MNOTE 'VARNAM=&VARNAM' results in the following in the assembly listing: +VARNAM=P1 so it appears that the creation of the compound variable name is working (compound being defined as the building of a variable name using two or more parts at runtime.) However, this statement: &XVAL SETC '&(&VARNAM)' results in the following in the assembly listing: ** ASMA003E Undeclared variable symbol; default=0, null, or type=U - TESTM/P1 ** ASMA435I Record 44 in S01CH.MISC.MACLIB(TESTMAC) on volume: TECH27 (and I might add that I get the same warning for the remaining variables, P2, P3, P4 P5 and P6) Which makes no sense since the macro is defined: MACRO &LABEL TESTMAC&P1=,&P2=,&P3=,&P4=,&P5=,&P6= Which, unless I've missed something, defines P1, P2, etc. Can anyone shed some light on why the assembler would think that the variables P1 thru P6 would be thought of as not defined when they are clearly defined in the MACRO template? Thanks, Chuck Charles (Chuck) Hardee Senior Systems Engineer Database Administration Information Technology Services Thermo Fisher Scientific chuck.har...@thermofisher.com -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: SV: Assembler programmers wanted - Clarification
Less of an outcry, but I would have pointed out that you can't talk about age. On 2012-03-22 11:40, Thomas Berg wrote: -Ursprungligt meddelande- Från: IBM Mainframe Assembler List [mailto:ASSEMBLER- l...@listserv.uga.edu] För Steve Comstock Skickat: den 22 mars 2012 15:06 Till: ASSEMBLER-LIST@LISTSERV.UGA.EDU Ämne: Re: Assembler programmers wanted - Clarification On 3/22/2012 7:54 AM, Ray Mullins wrote: I didn't think it was on behalf of Colesoft, so from my perspective you were already in the clear. I agree with Elardus -- Bob's heart was in the right place, but it didn't come out right. Yup. I imagine he thought he was doing the community a favor by announcing a job possibility and I'm sure he was caught totally by surprise by the response. I'd cut him slack: I think many of us learned a lesson or two here. Wonder what a response he had if he wrote "old, experienced assembler programmers are preferred" ? :) Regards, Thomas Berg __ Thomas Berg Specialist AM/DQS SWEDBANK AB (publ) -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Assembler programmers wanted - Clarification
I didn't think it was on behalf of Colesoft, so from my perspective you were already in the clear. I agree with Elardus -- Bob's heart was in the right place, but it didn't come out right. On 2012-03-21 14:27, David Cole wrote: Hi All, I just now came upon this thread, and I feel that I need to make a few of things clear: First, Bob is not making this appeal on behalf of ColeSoft. Second, Bob did not consult with me before making this posting. Third, if Bob had consulted with me, I would have told him not to do it. And fourth, I do not know for whom he is making this appeal. Frankly. I am embarrassed by Bob's posting, and I hope he doesn't do it again. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow Road VOICE: 540-456-8536 Afton, VA 22920 FAX: 540-456-6658 At 3/19/2012 12:10 PM, Robert Shimizu wrote: Folks: This is a community service announcement. While at SHARE, I spoke with a friend of mine who runs a software development house. He is looking for a couple of Assembler programmers with strong understanding of z/OS internal architectures. And, truth be told, he wants them to be as young as possible. If you know of anyone who seeks such a position, please have them respond to me directly and send me their resume. I'll see that introductions are made and will bow out after that. Sincerely, Bob -- Robert W. Shimizu Partner ColeSoft Marketing, Inc bshim...@colesoft.com www.colesoft.com (800) 932-5150 (928) 771-2005 Fax -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Assembler programmers wanted
Bob, Don is right. Although IANAL, I have taken enough recent classes in both HR and basic business legal stuff that if your friend stated those exact words in an interview, he would be violating federal law. It is even possible that your mention below has dirtied the hiring process. Please advise your friend that he/she needs to restate this and remove any hint of "looking for younger" hires. As Paul (I think) said elsewhere, the best path is to hire young and old and use the accumulated knowledge of the elder to mentor the younger. I'm glad to see an 18-year-old want to learn z/Architecture assembler, but the opportunities need to be created to allow this to happen. Again, IANAL, but I have book learning, which is almost as dangerous. ;) Later, Ray On 2012-03-19 13:15, Don Shaw wrote: Robert, Why are you participating in this illegal and scurrilous practice? On Mar 19, 2012, at 12:10 PM, Robert Shimizu wrote: Folks: This is a community service announcement. While at SHARE, I spoke with a friend of mine who runs a software development house. He is looking for a couple of Assembler programmers with strong understanding of z/OS internal architectures. And, truth be told, he wants them to be as young as possible. If you know of anyone who seeks such a position, please have them respond to me directly and send me their resume. I'll see that introductions are made and will bow out after that. Sincerely, Bob -- Robert W. Shimizu Partner ColeSoft Marketing, Inc bshim...@colesoft.com www.colesoft.com (800) 932-5150 (928) 771-2005 Fax -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Requiring FLOWASM for CBT donations
On 2012-02-27 22:32, Martin Truebner wrote: ... and it is one of the few programs that compile and run on either z/OS or z/VSE And, I would assume, CMS under z/VM. Has anyone tried it under Linux for z? -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Program FLIH
SAG did get rid of their famous one about 17 years ago, though. :) On 2012-02-23 17:37, Gibney, Dave wrote: Haven't looked, since I have Software AG, BMC, CA, SYNCSORT, LRS plus a few others, is it likely I will find it ? :) Dave Gibney Information Technology Services Washington State University If the address at location 1DC points to a page boundary it's most likely that the 3rd party code is installed. Happy hunting, Keven -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: FLOWASM observation
Might have to switch from RDJFCB to SVC 99... On 2012-02-21 10:17, Edward Jaffe wrote: On 2/21/2012 8:52 AM, McKown, John wrote: I keep my HLASM source in z/OS UNIX files. "Just because I want to.". This works well for me. The only problem that I've run into is when I edit with "vi" (yes, I get what I deserve). ISPF edit "knows" that if I replace "ABCD" with "EF", it should only move the non-blank characters immediately to the right of the "ABCD" left. vi doesn't do this. This is really disruptive of continuation characters in column 72. So, looked at FLOWASM. Wonderfully, one thing it allows is continuation of a statement without the continuation character in column 72! So I thought it would be wonder to use and remove all the characters from column 72. Unfortunately, FLOWASM uses RDJFCB on the DCB which describe the input dataset. This RDJFCB gets an RC of 4 when the input is a UNIX file.. It appears that the RDJFCB is really only used to pass back the DSN and volume of the input dataset to the assembler. I'm wondering if I have an old version and a newer version supports input from a UNIX file. Did I mention that I keep my macros in UNIX as well? Yes, I'm weird. I will take a look at this... -- 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/ -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: How good is the EX instruction?
On 2012-01-17 07:44, Edward Jaffe wrote: On 1/17/2012 6:40 AM, Paul Gilmartin wrote: I forget; is the target of EX treated as a data access or as an instruction access for cacne management? The 256-byte cache line containing the target instruction is loaded into I-cache. So, this would seem to point towards putting the target near the instruction, if you can, or at least no more than 244 bytes away (worst case, maybe a bit less), or possibly grouping frequently executed targets together using Martin T's. favorite LOCTR assembler instruction and hoping that the line stays in cache. Thoughts? Later, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: How bad is the EX instruction? (correction)
I knew there were VSE folks on those boxes, which is why I chose my models carefully. ;) On 2012-01-16 13:43, Tony Thigpen wrote: > I doubt anyone is still running ES 9000 boxes. I have paying customers on 9672s, MP2000, MP3000, etc. VSE, not z/OS. Tony Thigpen -Original Message - From: Ray Mullins Sent: 01/16/2012 01:48 PM Arrgh. Correction to the below. Not enough caffeine, yet it's late in the morning... Tom Marchant correctly mention that SRST/CLST came in with ESA, not late System/370, as a look at my SEARS card just confirmed. However, the point still applies - SRST/CLST have been around for almost 25 years and I doubt anyone is still running ES 9000 boxes. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: How bad is the EX instruction? (correction)
Arrgh. Correction to the below. Not enough caffeine, yet it's late in the morning... Tom Marchant correctly mention that SRST/CLST came in with ESA, not late System/370, as a look at my SEARS card just confirmed. However, the point still applies - SRST/CLST have been around for almost 25 years and I doubt anyone is still running ES 9000 boxes. On 2012-01-16 10:41, Ray Mullins wrote: On 2012-01-13 02:18, Rob van der Heij wrote: On Fri, Jan 13, 2012 at 8:13 AM, Martin Truebner wrote: Rob, have you tried SRST? I had a hard time getting used to SRSTs way of using/wanting the resgisters- but then... It does an excellent job on searching for one (and only one) character in a string. Martin, Haven't, and probably should for my own education. We restrict our products to older architecture levels for a number of good reasons. Ya-but... SRST came in sometime during the late System/370 era. I have a yellow book with SRST and CLST defined. (I've been burned only once by a non-System/370 instruction (ICM), and that was on a plug-compatible that a Brazilian customer was running in the early 1990s. I have burned myself on using the wrong ARCH option in a C compile when a customer was still running a z900 (ARCH(5)) and I had accidentally left it set to ARCH(6). Later, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: How bad is the EX instruction?
On 2012-01-13 02:18, Rob van der Heij wrote: On Fri, Jan 13, 2012 at 8:13 AM, Martin Truebner wrote: Rob, have you tried SRST? I had a hard time getting used to SRSTs way of using/wanting the resgisters- but then... It does an excellent job on searching for one (and only one) character in a string. Martin, Haven't, and probably should for my own education. We restrict our products to older architecture levels for a number of good reasons. Ya-but... SRST came in sometime during the late System/370 era. I have a yellow book with SRST and CLST defined. (I've been burned only once by a non-System/370 instruction (ICM), and that was on a plug-compatible that a Brazilian customer was running in the early 1990s. I have burned myself on using the wrong ARCH option in a C compile when a customer was still running a z900 (ARCH(5)) and I had accidentally left it set to ARCH(6). Later, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Enhanced CALL macro?
And YREGS. On 2012-01-12 21:17, Hall, Keven wrote: Have you forgotten about SAVE and RETURN in SYS1.MACLIB? IBM has you covered. Mostly covered, sort of...ish. K3n -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, January 12, 2012 10:43 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Enhanced CALL macro? On Jan 11, 2012, at 07:03, Rob Scott wrote: IMHO the first resource needed by any assembler programmer before writing anything non-trivial is a set of macros that enable subroutine calling, register saving and return that cater for all environments. Why doesn't IBM supply these and spare customers the redundant depletion of resource? -- gil -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Assembler pgm to copy a file
Not a bad idea. That does bring up other issues, but for the stuff I do, that would work. In case anyone is interested, having RSECT available would force reentrant assembly of the section even if someone forgot to put RENT in the ASM parms. On 2011-12-08 17:36, David Bond wrote: OPSYN is your friend. On Thu, 8 Dec 2011 17:27:46 -0800, Ray Mullins wrote: Bwahaha! Although things are better than they used to be... I'd still like the option for CEESTART to generate RSECT instead of CSECT... -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Assembler pgm to copy a file
Bwahaha! Although things are better than they used to be... I'd still like the option for CEESTART to generate RSECT instead of CSECT... On 2011-12-08 11:26, Tony Harminc wrote: On 8 December 2011 13:53, Tom Marchant wrote: Establishing the save area is important in the event of an abend if someone needs to follow the save area chain. It is difficult to determine from a dump where he saved his registers without following the conventions as they are documented in the Assembler Services Guide. This is especially true if there are multiple linkage stack entries used Maybe someone should clue the LE group in IBM into this... Tony H. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: ASM Program to copy a file
On 2011-12-08 09:43, Binyamin Dissen wrote: On Thu, 8 Dec 2011 17:14:38 +0100 Martin Truebner wrote: :>>> A change to MVC INOUTBUF(11),='Test record' works just fine. :>And MVC INOUTBUF,=CL(L'INOUTBUF)='Test record' would have worked as :>well. Unless INOUTBUF is longer than the literal and the literal is near the end of a page. During my years as computer lab manager at the college, that particular issue was the cause of many an S0C4 in assignments. The better students would catch on immediately, the good students understood when I told them why, the bad students made the same mistake over and over again. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: newer opcodes
On 2011-10-12 12:22, Edward Jaffe wrote: On 10/12/2011 5:08 AM, Tony Thigpen wrote: Our customers base is VSE. We have customers that are running (in production) old levels back as far as VSE 2.1. We have customers running hardware as far back as MP2000 boxes. Until last year, we actually had a VSE 1.4 customer. When you consider the fact that some of our customers are running non-Y2K compliant systems, it is a little scary! But, they keep sending in the checks. :-) We all have back-level customers. The real question is whether those customers--who won't upgrade their hardware and/or install new releases of the operating system--are upgrading to the latest releases of our software. When I looked at this a few years back, the answer was a resounding "No". Back-level customers were back-level on everything. And, when and if they did upgrade, they tended to upgrade everything at the same time. As long as we continue to support the highest release of our software that did not require newer instructions, the back-level customers continue to get what they pay for (support for their current release and access to new releases should they ever choose to upgrade) and we can develop the latest releases using newer hardware facilities. My internal rule-of-thumb (usually ignored) is to support the minimum hardware level that supports the last z/OS level to go EOS, and likewise the minimum supported z/OS level is the same. (If you need earlier, then you have to pay for it, just like you're doing with IBM, and you probably won't get a new release anyway.) This goes with both assembler (OPTABLE) and C (ARCH/TARGET) code. I haven't looked in about a year, but I'm pretty sure z/OS 1.8 and maybe 1.9 could still run on z800/z900. (In fact, I got a note from my former employer about a month ago concerning an LLH that sneaked into some assembler code in a maintenance branch.) As new releases come out, the release notes say what the minimum hardware and z/OS levels are, and also state that possible future releases may not support these levels. In the case of C, I set the TUNE parameter to one less than the current highest level for the most recent z/OS, because that usually aligns with the most common machine out there in The Real World ™. IIRC, z/VSE can run on even older architecture levels than z800/z900. I've written some assembler macros that simulate newer instructions and are loaded in based on the OPTABLE settings. It's kind of fun, actually, to rewrite newer instructions using only old. [Aside: No facility in recent memory has been more liberating to our programmers than the relative-immediate facility.] Amen. And when I've taught co-workers about the magic of relative branches when they need a new base register, their gratitude is bountiful. Later, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: oops - heavy finger
Well, there is a hurricane breathing down your neck, so we'll excuse it. :D On 2011-08-26 11:51, Thomas David Rivers wrote: Oops... Apologies for sending out my e-mail to the list, I had meant for it to go to Justin. I suppose it's "fat finger friday". - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: z12 new instruction list
On 2011-07-27 00:34, robin wrote: From: "Martin Trübner" Sent: Wednesday, 27 July 2011 4:43 PM What? z12 new box ? instructions maybe now we get DWIM? =Do what I mean. Still waiting for RSC (=Read and shred card). XO or XOPR (Execute Operator) is still my all-time favorite. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: Non-LE Assembler XCTL to LE C module with PARM=
On 2011-07-20 06:58, Kirk Wolf wrote: I apologize if this is a bit O.T., but the audience on this list seems to be a little more focused than IBM-MAIN for this kind of question What, ranting seems to distract them from the subject at hand? :) (This is one of the reasons I've been quiet over the past few years on lists: the signal-to-noise ratio, and lack of spare time.) I was curious about what would happen in the following scenario: Suppose you have a LE enabled "main" program written in C, that is normally invoked as a job step via "EXEC PGM=". The program accepts parameters in PARM=, but you can also set LE options for it (as with other LE programs) by putting them in the PARM before the first slash, e.g.: EXEC PGM=CLEPROG,PARM='HEAP(12M)/arg1 arg2". Now, suppose I have a small non-LE assembler program (call it "ASMXCTL"), that does a "XCTL EP=CLEPROG", passing the original R1 (PARM=).. What would happen if I did this? - EXEC PGM=ASMXCTL,PARM='HEAP(12M)/arg1 arg2' Does the "main" initialization of "CLEPROG" process the LE options as before? Yes. At a prior place of employment, there is actually C and assembler code that does this - dynamically generating HEAP settings based on various product options and then building the PARM that was passed to a subtask via ATTACH. (I inherited this code; the address space was a C main task with C and assembler subtasks fired off by invoking an ATTACH assembler subroutine, and those subtasks attached C and assembler subtasks. Should I mention that some of the assembler tasks were also not LE-enabled? Talk about the wide possibility of S0C4s. It was always on my list to convert to threads, but you know how priorities change on a whim from outside factors.) Later, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
Re: philosopy question: use LE & HLASM?
Paul's suggestion of LOCTR is how I solved the issue that hit me. I'd forgotten about that when I wrote my earlier note. I may have been absent from the list for a while, but long-timers remember me as being particularly "gripey". :) On 2011-07-08 05:03, Peter Relson wrote: However, use of RSECT in a multiple CSECT assembly allows a temporary override of NORENT The multiple CSECT assembly case had not come to mind. I think, while unwieldy, in many cases each such assembly could have its own *PROCESS RENT/NORENT. I don't claim that's better, just that until the "gripe" is satisfied, it might be acceptable. Peter Relson z/OS Core Technology Design
Re: philosopy question: use LE & HLASM?
Your points are certainly valid, Peter. However, use of RSECT in a multiple CSECT assembly allows a temporary override of NORENT, plus it's one less line (piddling, I know). I've never actually done a mixed CSECT/RSECT assembly, but I'm sure someone has...and with some of the new PM3 and 4 split formats, could be theoretically exploited. (Again, don't ask me why, I have no immediate idea.) In addition, unless something has changed recently, *PROCESS RENT can't be generated from inside a macro, but RSECT can. I've also seen issues in poorly-coded macros (not mine) where use of &SYSECT in CEESTART rather than the hard-coded CSECT would avoid conflicts. Later, Ray On 2011-07-07 04:36, Peter Relson wrote: This doesn't really sound like a philosophy question, it sounds like a need question. Do you need anything that LE can provide (be that functions or the stack or something else, even something that just makes it easier to code what you need to code)? If the answer is "yes" (or perhaps even "maybe" to help with future changes), then you should use LE. If not, then why would you? The LE stack is of course faster for an individual obtain than getmain but if all you need is one getmain, then the LE setup that would enable you to use that stack would be far more costly. Gripe time: Dear IBM LE, please allow use of RSECT in CEESTART. Perhaps I'm missing the benefit. RSECT is ignored within z/OS processing except for modules in IEANUCxx. So is there some assembler benefit over and above what RENT checking gets you? Wouldn't *PROCESS RENT CSECT (or having RENT in your assembler invocation parameters) basically be equivalent to RSECT Peter Relson z/OS Core Technology Design
Re: philosopy question: use LE & HLASM?
My philosophy has been to not use LE, unless LE will be around due to C/C++, COBOL, or PL/I being in the immediate vicinity. Also, there are times where I've had to use something in LE (like Lilian dates from an external source) that it handles nicely. If you are just using USS, and C will not enter the picture, then I'd not introduce the extra level of complexity. For example, at a former employer, I had to work with a batch program that did all sorts of BPX1 stuff (directory manipulation, spawning, etc.). It did not use LE. Gripe time: Dear IBM LE, please allow use of RSECT in CEESTART. The entry and exit code is pretty much reentrant already (for the most part). Love, Me Later, Ray On 2011-07-06 05:14, John McKown wrote: I am looking into writing an HLASM program on z/OS which will use UNIX System Services. Should I just bite the bullet and make my routine LE? -- John McKown Maranatha!<><
Re: ASMPUT and Windows x64
I finally got around to working on this. Here are some steps you need to do: The ASMPUTW.EXE (downloaded from ASM.SASMMOD2) cannot run on an x64 Windows system. However, it is just a self-extracting archive, and can be run on either an x86 Windows system or , even better, opened with your favorite ZIP archive manipulation tool (I used 7-Zip) and extraction performed. The SETUP.EXE program will run on Windows 7 x86 or x64. I could not get it to run on Vista x64 - it starts and hangs before presenting the dialog box, even with Win95 compatibility. However, ASMPUT does run under Vista x64, and with the right manual manipulations in the registry and file associations, it could be set up to work smoothly. As David wondered about below, you do have to run with compatibility on in Windows 7. I was able to use Win98/ME and Win95. One problem does crop up, however in Windows 7 - the File->Open and Open tool bar button do not work - they do not open the dialog box. However, you can double click on the .XAA file in Explorer and it will launch ASMPUT, opening the file. Under Vista, interestingly, I got it to run without compatibility. (Go figure). If anyone else wants to try this and runs into issues, drop me a note, and I'll try to assist. It's a shame that this program appears to be orphaned, based on the lack of ADATA V3 support and the lack of improvement since the Win98 era. If I were more of a Java hack, had more round tuits, and IBM were willing to pay me *cough*, I'd take a crack at porting and upgrading it. Later, Ray On 2011-04-28 15:42, David de Jongh wrote: I'd be interested to know if you can get that working. According to the doc (GC26-8711-08): Note that, as installed, the Program Understanding Tool toolbar buttons do not work on Windows 2000 or XP systems, and above. To resolve this, right-click on the Program Understanding Tool icon, and select Properties> Compatibility. Select Run this program in compatibility mode for: and select Windows 95 from the menu. Select Apply and then OK. Now the toolbar buttons should work. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.mrmullins.big-bear-city.ca.us/ http://www.the-bus-stops-here.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
ASMPUT and Windows x64
Hi everyone, It's been a long time! I tried installing ASMPUT (the Toolkit Program Understanding Tool) on a couple of Windows machines that are x64, and Windows did not understand *g* the program - giving the long-winded dialog box basically saying that this is x86-only. IBMLINK has nothing, and Google has about as much. Compatibility mode doesn't work either on both Vista and Win7. I could install it on an old home WinXP x86 machine, but I can't do that until this evening. There is one thing I could try after I install on x86, and that is copy the installed programs over to x64. Usually the installer is the one that has the issue with x64, not the actual installed program itself. This is how I got the old XMIT Manager to work. Has anyone ever gotten this working on an x64 machine? Cheers, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.mrmullins.big-bear-city.ca.us/ http://www.the-bus-stops-here.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté]
