Re: CLHHSI TYPECHECK(MAGNITUDE) Annoyance
On 2022-12-07 10:46 AM, Ed Jaffe wrote: We decided to replace many SS instructions with their SIL counterparts. One common case is frustrating. D501 C01E C020 CLC HWord,=H'-1' Is it negative one? A784 000C JE NegOne Branch if yes replaced with: E555 C01E CLHHSI HWord,-1 Is it negative one? A784 000C JE NegOne Branch if yes ** ASMA320W Immediate field operand may have incorrect sign or magnitude - -1 I totally understand the warning in this case: E555 C01E CLHHSI HWord,131071 Is it negative one? A784 000C JE NegOne Branch if yes ** ASMA320W Immediate field operand may have incorrect sign or magnitude - 131071 but I can't understand why -1 generates this warning. The provided value is validly within the range -32768 through 32767. We like TYPECHECK(MAGNITUDE) and quite literally assemble tens of millions of lines of code daily with it enabled and no such warnings are produced. So we're forced to use ACONTROL like this around this bizarre case: PUSH ACONTROL ACONTROL TYPECHECK(NOMAGNITUDE) E555 C01E CLHHSI HWord,-1 Is it negative one? A784 000C JE NegOne Branch if yes POP ACONTROL It seems a ridiculous misunderstanding on the part of the assembler... Maybe replace CLHHSI with CHHSI, which is designed for signed values: D501 D146 D144 01E6 01E4111 CLC HWORD,=H'-1' A784 FFE5 0114112 JEEXIT E555 D146 01E6 113 CLHHSI HWORD,-1 ** ASMA320W Immediate field operand may have incorrect sign or magnitude - -1 A784 FFE0 0114114 JEEXIT E554 D146 01E6 115 CHHSI HWORD,-1 A784 FFDB 0114116 JEEXIT -- 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/
Re: Generating a TR field
On 2022-05-26 19:08 PM, Charles Mills wrote: OP did not ask how to do the translate. OP asked Is there a slick way or a macro to build the TR table? True. I should leave it to Gil. -- 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/
Re: Generating a TR field
On 2022-05-26 18:26 PM, Charles Mills wrote: And what is that? Some comments? Probably the actual TR instruction. -- 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/
Re: Unexpected C code
On 2022-04-21 10:46 AM, Seymour J Metz wrote: Well, in the case of S/370 the compiler could emit JO or JNO after the add. Well, if only JO and JNO had existed in the days of S/370... -- -- 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/
Re: Type attribute for data
On 2021-12-28 15:36 PM, Joseph Reichman wrote: I am going through a copy book in a macro Via the AREAD assembler instruction the copy book is a Dsect It seem whether data is defined ds cl6 or ds pl6 the T’ is always a C if it’s defined storage as a constant I.E DC Pl6 would be P Is there a question in there somewhere? -- 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/
Re: Curious compiler optimization
On 2021-11-16 10:44 AM, John wrote: ...deliberately...on purpose. I can understand that you are disappointed with the code that is generated when you don't request optimization, but I absolutely don't get your assertion that the compiler would generate poor code on purpose. -- 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/
Re: A faster replacement for L R15,=A(EXTRN)
On 2021-01-15 11:55 AM, Gord Tomlin wrote: It's been possible to achieve the same result with LARL for many years (requires the use of the GOFF option in the HLASM parameters). Since I got called out on the above, I ran some tests to refresh my memory. The following code: EXTRN FOO LARL R15,FOO assembles cleanly with the GOFF option specified, but without GOFF the following warning message is issued: ** ASMA215W Relative Immediate external relocation in NOGOFF object text - FOO Regardless of whether GOFF is specified on the assembly, the output object module can be used to create a load module in a PDS. Revised: "It's been possible to achieve the same result with LARL for many years (a warning message will be issued if GOFF is not specified in the HLASM parameters)." -- 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/
Re: A faster replacement for L R15,=A(EXTRN)
On 2021-01-15 11:27 AM, Don Higgins wrote: With the recent HLASM and z390 support for 32 bit relocatible immediate fields, it appears that for amode 31, the IILF insert immediate instruction is a more efficient way to load a register with an external address than using the traditional L load instruction to fetch an address constant. The 6 byte insert immediate instruction can replace 8 bytes for the load and address constant. And the insert instruction avoids having to add base and displacement address and then load the separate address constant. It's been possible to achieve the same result with LARL for many years (requires the use of the GOFF option in the HLASM parameters). -- 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/
Re: PC Backup best practices
On 2020-08-13 20:25, Don Higgins wrote: I know some people use cloud backup, but I don't think it would be as fast. I also worry about cloud security. Given that it's preferable to have a backup copy at a separate location, cloud backup is probably the most convenient means to achieve that. It's not going to be as fast as local backups, but still probably faster than your sneakers or your car. Some cloud backup vendors offer zero-knowledge storage, where the vendor does not have the ability to read your storage. Alternatively, you can use a product like Boxcryptor to encrypt files locally before sending them to the cloud. -- 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/
Re: how to return?
On 2020-08-11 13:57, Tony Thigpen wrote: code that 'fixes' R14 Personally, I'm not a fan of that. I want to see the caller's actual R14. > CLI 0(R14),X'0C'BASSM? > BER14_OK > CLI 0(R14),X'0D'BSM? > BER14_OK The program containing this code is specified to be AMODE ANY. If it is called such that it is entered in AMODE 24 and the caller is not AMODE 24 and not below the line, things won't end well. -- 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/
Re: Poll
POps, because it's like an all-knowing father figure for all of us. NyQuil, because it's...so... On 2019-09-16 15: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 -- -- 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/
Re: Loading a VCON with as an immediate value
On 2019-06-19 16:06, Charles Mills wrote: Believe it or not, the binder*will* resolve it. Requires the binder and perhaps GOFF. It does require GOFF, which in turn requires LIST(133). -- 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/
Re: Address Space Storage Map
On 2019-05-27 08:26, Joseph Reichman wrote: Hi From the CVT I can get M,F,L Extended LPA Start and Ending Storage Ranges and I can also get Nucleus Extended Read Only and Read Write Starting and ending Ranges From the LDA I can get Private / Extended Starting and Ending Private Ranges From the GDA I can get SQA and CSA / Extended Starting and Ending Ranges The Only thing that Escapes me is LSQA If anyone can Help would appreciate it Thanks Help us to help you. Please be specific as to the situation in which you want to find this information. Is it in a running address space? In a dump? Something else? -- 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/
Re: Best practice using Conditional Assembly
On 2019-03-10 18:27, Jon Perryman wrote: In this case, it's not archaic. Column 16 is the standard assembler continuation column. His assembler colleagues can't complain about that. They are complaining about clean compiles and debugging strange program behavior because the label is in the wrong column. How many times did I repeat the bug and he still says I'm complaining about the archaic fixed format (Even with source demonstrating the problem). Jons On Sunday, March 10, 2019, 1:47:02 PM PDT, Paul Gilmartin <0014e0e4a59b-dmarc- >On 2019-03-10, at 04:50:11, Tony Thigpen wrote: If you are fussing about the fixed-format of the input, That's painfully archaic. Jon and Tony, could you please take this fight private. This is getting old. -- 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/
Re: EX
On 2018-08-06 10:35, Ed Jaffe wrote: We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail with an 0C1. 'EX 0,*' was my old standby, but 'Jxx *+2' eliminates the need for a code base register and so is more generally usable in modern code. -- 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/
Re: EQU * considered harmful
On 2018-08-01 18:49, Charles Mills wrote: See you in STL? 'fraid not. Nose to the grindstone. -- 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/
Re: EQU * considered harmful
On 2018-08-01 16:41, Charles Mills wrote: "Avoid instructions (executable code) and operand data (working storage or stack storage) in the same cache lines; which can be costly due to moving cache lines between the separated (split) local caches (instruction/data L1/L2)" -- C. Kevin Shum, Distinguished Engineer, IBM z Systems Microprocessor Development (March 2016) Charles Exactly. "Mixing executable code and operand data considered harmful" And if you always avoid mixing instructions and operand data, using EQU * for labels in code is no longer potentially harmful. We're on pretty safe ground if we assume IBM will always only create instructions that are an even number of bytes in size. I prefer, and always use, DS 0H for labels in code, but if EQU * causes problems in your code you have other things to clean up. Here's one to rail about: branching to a hard coded offset from the current location, e.g., B *+12 This is a tire fire waiting to happen. -- 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/
Re: New Metal C standalone product for z/OS
On 2018-07-17 12:45, John McKown wrote: Looks like IBM is really trying to eliminate HLASM programming in the user community. Or, perhaps, extend the community to include C "systems" programmers (like with a UNIX background). http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/6/897/ENUS218-326/index.html=en_locale=en IBM Enterprise Metal C for z/OS Trial, V3.1 is an evaluation release of the Enterprise Metal C for z/OS, V3.1 product that is available with a 90-day evaluation license at no charge for non-production use. It is available from IBM Shopz. Enterprise Metal C for z/OS is the newest, stand-alone offering for the IBM family of development tools. Enterprise Metal C for z/OS delivers a high-level language alternative to having to write programs in High Level Assembler (HLASM). The ability to write programs in HLASM is a specialized skill for the z/OS platform and developers with expertise in assembler skills are difficult to find. Developers can use C syntax instead to develop systems programs. This eliminates the need to manage the use of registers and to manually tune assembler instruction sequences. Enterprise Metal C for z/OS does this for developers. Enterprise Metal C for z/OS allows developers to create high-performing, low-level, free-standing applications. The generated optimized HLASM source code is independent of the Language Environment runtime, and the C runtime is not required for execution. The resulting programs seamlessly integrate with the HLASM code base to provide direct access to z/OS System Services. Enterprise Metal C for z/OS takes advantage of IBM optimization technology to generate high-performance, optimized code. Develop applications with Enterprise Metal C once, and then recompile to optimize for future advancements of IBM z/Architecture® systems. I don't see anything in the announcement that suggests any new functionality has been added to Metal C. -- -- 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/
Re: FIND or INDEX builtin function
On 2018-03-01 08:17, Gord Tomlin wrote: On 2018-03-01 03:16, Keven wrote: Alas the assembler doesn’t execute in-line assembly language That wouldn't be much of an assembler. Are you working with something other than IBM HLASM? My bad, Keven, you were pointing out that execution-time code can't be run at assembly time. The coffee hadn't kicked in yet. -- 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/
Re: FIND or INDEX builtin function
On 2018-03-01 03:16, Keven wrote: Alas the assembler doesn’t execute in-line assembly language That wouldn't be much of an assembler. Are you working with something other than IBM HLASM? -- 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/
Re: Fair comparison C vs HLASM
On 2018-02-05 00:54, Jon Perryman wrote: C is NOT portable. Portable languages must be usable (acceptable) on a platform's as it exists. zArch became a portable platform after hardware changes added String (and other) instructions. These instructions were not added for MVS because we lived without them for several years. This is the best example of "motivated reasoning" that I have seen in this lengthy thread. The world is full of packages written in C (and many other languages) that can be run on numerous different platforms; in most cases, all that is required is running a build for that platform. Conversely, you cannot run HLASM on a computer that does not support z/Architecture or its ancestors, unless you have a legal or illegal product that emulates said hardware architecture to run it on. Calling z/Architecture a "portable platform" is inverting the whole concept of portability (actually, "cross platform applications"). You port the software to the hardware. As I've said before, I'm not here to defend C; it has some serious defects and, FWIW, Dave Cole's piece was not specific to C. HLASM has its place, and I continue to do the majority of my work in it (because of the nature of my work), but its place isn't "everywhere". I'm just a little taken aback by the complete dismissal of the advantages of compiled languages in general, and I'm a bit puzzled by the vitriol. -- 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/
Re: Fair comparison C vs HLASM
On 2018-02-02 09:45, Charles Mills wrote: I wonder, have machines changed at all since 1989? Any new instructions on the Z? The "problem" is fixed in C++ -- Google std:string. or std::string -- 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/
Re: Fair comparison C vs HLASM
On 2018-01-30 12:33, Kirk Wolf wrote: My favorite comments related to this subject came from Dave Cole on the Assembler-List last October, which I will re-post below because it deserves more bits of storage. Kirk, I was sorely tempted over the last few days to dig out this gem and post it. It's very instructive to read the HLASM code generated by the compilers when optimization is in effect. Attempting to achieve the same level of pipeline and cache friendliness, etc., when hand-writing HLASM is a big chore and a definite impediment to programmer productivity. -- 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/
Re: Fair comparison C vs HLASM
On 2018-01-23 10:06, Jon Perryman wrote: I'm not sure what RYO is. RYO is a TLA for "roll your own". On 2018-01-22 11:59, Gord Tomlin wrote: Most programmers (whether C or Assembler) would not write their own XML parser. They would call a pre-existing parser. FWIW, in the past, I've done RYO parsing in both languages, and it was less work for me when I did it in C. All I was saying here is that I have in the past rolled my own XML parsing in both C and Assembler, and doing so was quicker and easier in C than in Assembler. Having said that, it didn't take long to realize that it was much easier to use an off-the-shelf parser than to roll my own in either language. -- 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/
Re: Fair comparison C vs HLASM
On 2018-01-22 10:44, Jon Perryman wrote: I also commented that C is a weak language compared to HLASM and gave some examples that force bad coding techniques (e.g. XML parser). A C programmer took offence because he had written an efficient XML parser in C. Most programmers (whether C or Assembler) would not write their own XML parser. They would call a pre-existing parser. FWIW, in the past, I've done RYO parsing in both languages, and it was less work for me when I did it in C. I'm not here to defend C. It certainly has its warts. But just as it's not good for C programmers to proclaim C to be better than Assembler in each and every case, it's not good for Assembler programmers to do the reverse. Both languages have their places, and there are also many situations where neither one is the best choice. -- 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/
RFE: Add support to EDCDSECT for generating Doxygen-compatible comments
All, I've submitted a new RFE for z/OS XL C/C++, requesting that its comment generation be enhanced so that it can generate comments that are recognized by Doxygen. This should be helpful for anyone that shares data areas between Assembler and C/C++ code. Here's a link to the RFE: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=92319 If you like it, please vote for it! Thanks! -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: better way? C language x'00' delimited string.
On 2016-06-28 13:53, John P. Hartmann wrote: Oh yes, the null will be. It will be in the line below your DC where the assembler prints the expanded statement. On 06/28/2016 05:45 PM, John McKown wrote: Even after assembling, the will be in the listing not an actual x'00'. Another good reason to use a macro. The macro could include: PUSH PRINT PRINT NOGEN bla bla bla POP PRINT -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: better way? C language x'00' delimited string.
On 2016-06-27 09:04, John McKown wrote: COBOL has succumbed to C interface by offering the Z'Character String' which automatically puts a x'00' at the end. I want to do this in HLASM. Originally, I did: STRING DS CL7 ORG STRING DC CL6'HELPME' DC X'00' But that is really odoriferous. So now I do: SETC BYTE(00) STRING DC 'HELPME' Not quite as pungent, but better. Does anybody have a better way? Should I just make a macro, perhaps DCZ, to do the above for me automatically? This is more a technique question than a technical one. What would be more understandable to most HLASM programmers? I'd say use a macro, and use a name for the macro that advertises what the macro generates. IMHO something like CSTRING would be more descriptive than DCZ. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: Microprocessor Optimization Primer
On 2016-04-02 14:13, John P. Hartmann wrote: Last I heard SLR was seriously discouraged. because it stalls the pipeline where the others don't. I hadn't heard that one, but would be quite interested to hear whether it is true. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: Csect - Dsect Question
If we're insisting on correctness (I wasn't, since Ed just blasted code from his head into an email), LOAD has no EPNAME argument. Coded as below, EPNAME should be EPLOC. On 2016-04-01 03:14, mar...@pi-sysprog.de wrote: The complete "corrected" version of the loading is this .. LOAD EPNAME==CL8'MSGTABLE'Load external message table LLGTR R0,R0clean high order word and low high order bit NILL R0,X'FFFE' (same) STG R0,MsgTable Save clean table address ... -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: Question of curiosity: Why are IVSK and TPROT instrictions privileged?
On 2015-10-26 18:41, Farley, Peter x23353 wrote: Again, I don't see any "ways that compromise security/integrity" here, from an application programmer's point of view, but maybe I just don't think like a black hat. "Validly use" is too strong, I think. As I said in my earlier response to Chris C., the usual application programs only need to deal with addresses in their one and only address space, and if written to avoid abends may want to know that an address is valid in the address space and whether it can be read from or written into. State changes of the types discussed so far are usually unlikely in such applications, so why isn’t this usage "valid"? I accept that my POV here may be far too narrow to see the forest for the trees. Peter In an address space with multiple tasks (which is certainly not uncommon these days), it is always possible for task A to release storage that task B wants to use. If the storage is freed between your TPROT check and your actual storage access, then you could abend. If the storage is freed and then the same virtual storage address is obtained for something different before you get around to using it, then the results are unpredictable. TPROT does not actually tell you whether the input storage address is GETMAIN-allocated. It just tells you that some storage in the page containing the address is GETMAIN-allocated. And on a z13 with OA46291 applied, you should not count on even that being true. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: Redesigning the Principles of Operation Manual
On 2014-11-13 20:28, Tony Thigpen wrote: Something for an intern I assume this was tongue in cheek! The most important attribute of POps is correctness. No offense meant to interns, but I suspect that correctness would suffer if the POps was turned over to interns. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: How to assign length of generated instructions to macro variable?
On 2014-08-18 16:18, Peter Hunkeler wrote: I'll have to think how some of them may help me to find a solution that will issue an MNOTE, not an assemlby error because of some statements like the above DS instruction. Personal taste is personal taste, but if I had a situation where I attempted to add more to a work area than it could hold, I would want to be hit on the head by the assembler as hard as possible. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: ASSEMBLER-LIST Digest - 20 Feb 2014 to 21 Feb 2014 (#2014-29)
On 2014-02-24 10:09, John Walker wrote: Mixed case is industry standard? What industry, mainframe assembler, or C programming industry standard? Come on. This is just more C programmers trying to foist the mixed case abomination off onto the mainframe in order to make us conform to what they are used to. Honestly, it IS more error prone to have that ridiculous mixed case approach than mono-case. Upper or lower, I don't care which, but it DOES avoid more headaches. And the 'headaches' that are described for the pre-trained mixed-case readers is because of a normal need to de-train your mind from mixed case reading. I encountered the same situation when I first entered the mainframe area. That's normal. However, trying to make all mainframers, admittedly a small group now, to conform to you is a bit pushy, wouldn't you think? The discussion here has been about HLASM accepting mixed case input, not about it being sensitive to the case of an identifier. Mixed case text is demonstrably easier to read than all upper case. On the other hand, there has been no shortage of problems in case-sensitive languages such as C involving two identifiers differing only in the case of a single character. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: Carmine Cannatello's book
On 2014-01-15 17:17, Tony Thigpen wrote: (Most Mainframe assembler programmers did time as a COBOL programmer.) Interesting assertion. The majority of systems programmers I know did not come from an applications programming background. Personally, I've only written one COBOL program since university, which means it's the only one I wrote without using a keypunch. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: Carmine Cannatello's book
On 2014-01-15 18:03, Tony Thigpen wrote: Are you saying that all assembler programmers (including those on the Assembler-List) are only for Systems Programmers? Nope. I am sure there are a lot of assembler application programmers here also. Maybe, but the majority of the conversations here appear to discuss topics of interest to systems programmers. Nevertheless I should not generalize. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: PC Based IDE for use with Mainframe
On 2014-01-14 13:28, Tony Thigpen wrote: (Cross-posted VSE-L, VMESA-L, Assembler-List) Just received my Enterprise Tech Update and it had an item about IDEs for the mainframe: * Tech Talk: Eclipse — Welcome to the Future of Mainframe Development by Jim Liebert. Eclipse has come to the mainframe and is likely to change the way programmers accomplish work for years to come. http://entsys.me/1n1qk I have used Eclipse in the past. (Took a few Web Development classes at the local college.) But, I never looked at it from a Mainframe Development point of view. I am currently doing all my assembler development (mainly VSE) on a pc using the Dignus assembler, then transporting the objects to be linked on VSE. I would like to get some feedback from anyone who uses an IDE for mainframe development, specifically for COBOL and Assembler coding. For example: How are you handling the change from a 3270 style editor to a pc style editor? I currently edit my pc stored mainframe assembler code using XTHE (The Hessling Editor) because it works like z/VM's Xedit. Every time I have attempted to use a PC based editor, it just does not seem to have the flexibility I find with Xedit. Especially, the ability to use home-grown prefix-area macros. Also, column positions are so important to COBOL and Assembler and it seems that most pc editors are designed for free-form source like C or java. Have you found decent IDE plug-ins for your languages? Is the time right for moving to a pc based IDE for mainframe development? Tony Thigpen Brave question...prepare for a religious onslaught! ;) Personally, I don't think many of the benefits of an IDE are as applicable to Assembler as they to other languages. For languages such as C++ and Java, an IDE can do extensive lookups of method and property names, provide auto-completion of names that are often long, catch syntax errors on the fly, etc. There simply isn't as much of all that in Assembler. We develop one of our components cross-platform on a PC using Dignus. However, this component is largely C and C++. I use jEdit as an editor and make to do the builds. Like you, we send the object modules to the mainframe and link edit there. Most of the Assembler code for the component is kept on z/OS. You will likely get a different opinion from each person that responds. Personally, I would rather use ISPF than anything else for Assembler and JCL, but I would rather use almost anything but ISPF for many other things, like C, C++, Java, HTML, PHP, etc. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: OT: SI units and precision
On 2014-01-04 07:20, Dougie Lawson wrote: At the same time we need the Gov't here in the UK to switch from miles, miles per hour, miles per gallon and pints to Km, Km/h, Litres / 100Km and half litres (it's only 68ml short of a pint). Some might be a bit upset about losing 68 ml from their pint! -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: Relative Branches / IBM macros
On 2013-11-14 14:18, Steve Smith wrote: External relative addressing does work, yet HLASM still warns about this, e.g. ASMA215W Relative Immediate external relocation in NOGOFF object text - ESTAE_RESUME Is there any cure for this? My production build process doesn't tolerate any return code that isn't a multiple of 0. I haven't tried it, but I'd guess that if you tried to run such a module through the old linkage-editor that it would produce a suitable error message. So there shouldn't be any need for the HLASM warning. sas We dealt with that by adding GOFF,LIST(133) to our HLASM options. The linkage editor happily processes the resulting object modules. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Sortlessness?
Just a little Friday afternoon curiosity...does anyone have, or know of, any z/OS systems that have *no* sort product (DFSORT, Syncsort, etc.) installed? Before anyone asks, no, I am not planning to develop one! -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: Canadian GAAP?
On 2013-08-09 10:26, Paul Gilmartin wrote: Friday. I understand that Canada is abolishing its one-cent coin. So will cash register transactions be rounded to multiples of $0.05? How about electronic transfers, account balances and checks? Will Canada's version of GAAP be adjusted accordingly? And most relevant here, can DFP handle rounding to multiples of 0.05? One could always multiply by 2; round to a multiple of 0.10; divide by 2. Enormous reprogramming task. I suspect that accounting will continue to use a granularity of $0.01. -- gil If you go to Starbucks and your coffee is $2.57 after tax, and you pay $3.00 cash, you will receive $0.45 change. If you pay by debit/credit card, you will pay $2.57. The one cent unit of value has not been discontinued, just the piece of copper that was worth well over one cent. I can't speak to how the rounding for cash transactions is reflected in accounting. I suppose you could check with the Canadian Institute of Chartered Accountants. http://www.cica.ca/index.aspx This issue transcends Assembler and, for that matter, System Z. Anyone doing accounting for cash transactions on any platform using any language will need to confront it. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: APL or IUP
On 2013-07-30 20:49, John Ehrman wrote: Dave Gibney guessed: I will guess IUP to be Independent User Program. I believe it's Installed User Program. Yep. There were also products called FDP (for Field Developed Product).
Re: TRTE, etc.
Well done, Paul! Your post was only five minutes ahead of the blessed event! On 2013-04-19 12:58, paul schuster wrote: It needs to be remembered that Mr. Gilmore 'left' this list several years ago under this same sort of pretense, but surfaced again not-too-long later. So we only have to wait him out. Thank you.
Re: Length question
Jon and Ken did not say that they are avoiding the use of TRTE due to unfamiliarity with the instruction. They indicated that they are avoiding the instruction because it may not be supported on all machines where their code must run. Specifically, the TRTE instruction will cause an operation exception if the parsing-enhancement facility is not installed. This facility was not added to z/Architecture until the seventh edition of z/Architecture Principles of Operation. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2013-04-13 14:44, John Gilmore wrote: It must be conceded that TRTE is newer than TRT, but it is not a notably new instruction. More to the point, while it is may be appropriate to supply a TRTE macro for use on old hardware, it is not appropriate to avoid the use of the TRTE instruction where it is available, as is now usually the case. I of course expected this response. Litanies in defense of the old and familiar are recurrent here, but repetition does not make them meritorious. They are of a piece with the suspiciously repetitive, insular, risk-averse, mediocre notions that are ruining, have indeed largely ruined, the mainframe, a splendid platform that is now used in mostly ignominious ways. John Gilmore, Ashland, MA 01721 - USA
Re: Length question
Many companies do not see the depreciation interval for a purchased mainframe to be an automatic trigger for the purchase of a new replacement mainframe. Instead, some of them quite enjoy the lack of hardware expenditures. We often encounter old machines at customer sites, and must make sure that our code runs successfully on *all* machines that are supported by the base level of z/Architecture. I am certain that you will receive a similar answer from many of the others on this list who develop code for a broader audience than their own companies. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2013-04-13 17:44, John Gilmore wrote: As I attempted to make clear in my earlier post, this old-hardware argument is specious. If you want to support old machines, write a macro called TRTE for them, but use TRTE in your code. It reduces clutter, increases readability, improves performance where the instruction is installed, etc., etc. Note also that the '7th edition' of the PrOp was published in 2008 February, a bit more than five years ago and longer than the depreciation interval for a purchased mainframe. I have made my views and the reasons for them clear. Others are of course free to do as they think best. How not? John Gilmore, Ashland, MA 01721 - USA
Re: Length question
Certainly he can write such a macro. Whether it is wrong or not depends upon, among other things, whether one of the older machines he needs to support is the one where he must do his development and testing work. If that is the case, then he will lack the ability to test INST on a machine where it is supported as a machine instruction, and it would be irresponsible for him to ship code he cannot test. There are instances where it is beneficial to simulate a machine instruction with a macro for environments where the hardware does not support the machine instruction. However, every case must be evaluated on its own merits. Among other things, if the code is part of a product that is distributed OCO, it must either be multi-pathed to always select the correct implementation or be shipped in a separate version for each machine level. The benefits of exploiting the machine instruction where it is available must be weighed against the overhead of the code that selects the code path and the cost of testing on multiple machines. A blanket suggestion that such a macro is always a good idea is simply incorrect. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2013-04-13 17:51, John Gilmore wrote: Kenneth Meyer's formulation begin extract I, among many, have to support older versions of the mainframe. This means using common instructions rather than the latest instructions. /end extract is admirably clear and succinct. Its only defect is that it is wrong. If instruction INST is not available on some of the machines he must support he can write a macro definition called INST that mimics its behavior for use on these antediluvian machines, do very much the same thing IBM does for millicoded instructions, albeit somewhat less elegantly. John Gilmore, Ashland, MA 01721 - USA
Re: Usefullness (or not) of STOC/LOC instructions?
Paul, I saw Dave's post here on ASSEMBLER-LIST and replied to it here on ASSEMBLER-LIST before I was even aware that Dave had also posted it on IBM-MAIN. Dave has posted here several times before, and FWIW I think his post was quite appropriate for ASSEMBLER-LIST. After all, one of his products *is* and assembler! -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-11-28 08:45, Paul Gilmartin wrote: Why do people find it so hard to reply to the same list on which the original message appears? I don't know that I've seen Dave on ASSEMBLER-LIST. On Nov 27, 2012, at 12:16, Gord Tomlin wrote: Dave, can you repost your instruction sequences one above the other? For me, they are garbled and I can't tell what the two sequences are. On 2012-11-27 11:19, Thomas David Rivers wrote: For example, the following two instruction sequences are equivalent. STOCG 15,256(7),8 BC 7,SKIP STG 15,256(0,7) SKIP DS 0H I'd reconstruct it as: STOCG 15,256(7),8 BC 7,SKIP STG 15,256(0,7) SKIP DS 0H -- gil
Re: which instructions should I use?
Instructions that are not supported on all z/Architecture machines can generally be identified in the Principles of Operation by the presence of an entry under Program Exceptions in the form: - Operation (if the such-and-such facility is not installed) -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: which instructions should I use?
On 2012-08-28 11:24, McKown, John wrote: Yes, but I cannot simply relate the such and such facility to an actual processor. Except by looking at the documentation for the processor. I would like the reverse mapping. I.e. look for such and such facility and get a list of current processors which support it. I am not aware of such a thing as a one stop shopping center. It is definitely much more work to find this information than it should be. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: Subject: AW: ** ASMA030E Invalid literal usage - =CL8'MARTINWH'
Maybe there's hope: http://www.mozilla.org/en-US/b2g/ -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-07-12 19:28, Paul Gilmartin wrote: On 2012-07-12 16:33, Edward Jaffe wrote: On 7/12/2012 9:56 AM, McKown, John wrote: Which is totally simplistic these days. You bought your cell phone, right? Do you really think that you can do anything to it that you want to? And that it is totally documented? In today's IP is __mine__ world, more and more things are becoming black boxes. No user serviceable parts in side. I am not afraid to 'root' my Android phone. If I had an iPhone, I would 'jail-break' it for sure! http://www.gnu.org/philosophy/right-to-read.html Read it and weep. There's a difference, not only in price but in that Android doesn't publish a Redbook touting the facility to run open Linux. (root has a Strine etymology, hasn't it?) -- gil
Re: Base registers
You can refer to entry points outside of the current CSECT if you specify the GOFF assembler option. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-06-19 10:04, Paul Gilmartin wrote: On Jun 19, 2012, at 07:51, McKown, John wrote: ... I prefer using Branch Relative, Relative (such as LARL vice LAY), and Immediate (such as LHI vice LH) instructions. And I do recognize that it is not always possible, such as accessing locations outside of the enclosing CSECT. That would require an enhancement to Binder. But that's not unthinkable. But it would introduce a class of addressability errors that could be detected only at link time, not at assembly. Probably not justified by ROI. -- gil
Re: Base registers
Why don't we jump to the underlying notion of the jump instructions, or more accurately branch relative instructions, which is relative addressing: relative address oriented programming. I'll admit that it's not concise, but I'm optimistic we won't have a religious war about the resulting acronym. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-06-17 09:05, John Gilmore wrote: Words can of course have different specialized meanings in different contexts, but there is ordinarily an evolutionary path between these meanings. Physicians, for example, talk of senile changes, meaning those associated with aging, in a way that is entirely devoid of pejorative intent. Or again, Chaucer and his contemporaries used the word lewd to mean lay, not in holy orders; but there is a path between this meaning and the modern one: the clergy did not often make what we call lewd gestures in public. I myself find 'baseless' very unsatisfactory, in part because it is not at all transparent. Thus, while I have no emotional investment in the term jump-based, I do believe a new one is needed; 'baseless' can scarcely avoid connotations of dispensability when in fact it is the base registers that are largely dispensable. We need to look forward to a time when the use of base registers, multiple ones in particular, and the arbitrary segmentation of code into 4096-byte pieces will be perceived as a quaint, historically interesting but obsolete practices; and a new contrasting term will be helpful in changing the current vulgar mind set. (Mr Gilmartin's use of vulgar, which evolved from the Latin phrase mobile vulgus, is open to criticism; but that is a subject for another time and place.) Alternative suggestions? John Gilmore, Ashland, MA 01721 - USA
Re: anti 4095 base guys
The displacement for A is treated as a 12-bit *unsigned* binary integer. The displacement for AY, AG, AGF, AGSI and ASI, is treated as a 20-bit *signed* binary integer. I contributed the asterisks. The rest is from the POps. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2012-06-04 15:20, McKown, John wrote: No such thing as a negative displacement. A displacement is more like an unsigned immediate operand. From 0..4095 (0x000 to 0xFFF for a 12 bit displacement) or 0..1048575 (0x0 to 0xF for a 20 bit long displacement). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Jan Ott Sent: Monday, June 04, 2012 2:14 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: anti 4095 base guys i guess you guys would never set the base to he last byte of the program or dsect; having all negative displacements.
Re: Title: V1R6 Language Ref
On 2012-04-30 11:33, Steve Comstock wrote: Ya' know, if you download the docs you want as PDFs, then using Windows Explorer you can list your directory (sorry, 'folder') and use View - Choose Details ... then select 'Title', your directory list will include the title (well, for the vast majority of the docs) and there the HLASM docs have 'HLASM' in their title I'm just sayin' ... :-) Of course that would relegate him to viewing his manuals as PDFs. Not all of us like that choice! Jus' sayin' ;) -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: DataSpace LOAD
On 2012-03-05 14:59, John Gilmore wrote: You can 'extend' 64-bit storage too, essentially without limit. There is no longer any rationale for defining new data spaces. As usual, there may be good reasons for keeping some of those you already have in use. John Gilmore, Ashland, MA 01721 - USA If you have data areas that should survive beyond the life of the address space that created them, and you want control over who can work with those data areas, then there are still some advantages to data spaces over 64-bit storage. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: Need simple example - Calling c subroutine like printf from HLASM program
You want to make sure you are not creating and destroying a LE environment for every call, or it will get expensive. If your calling Assembler program is Language Environment-conforming, have a look in z/OS V1R12.0 Language Environment Writing ILC Applications, section 14.5 Assembler Main Calling HLL Subroutines for Better Performance http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA4180/14.5?SHELF=cee2bkc0DT=20100628162151 If your calling Assembler program is not LE-conforming, go to z/OS V1R13.0 Language Environment Programming Guide, 5.3 Chapter 30. Using preinitialization services to read about the use of CEEPIPI http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA21C0/5.3?SHELF=cee2bkc0DT=20110618162445 -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 On 2011-10-14 09:33, McKown, John wrote: I know that I've seen somebody do this before. But I cannot remember how they did it. Does anybody have a code snippet that shows how to call a C subroutine like sprintf() or strncmp() from HLASM? Also the compile link JCL would be appreciated. I've tried reading the LE manuals and the C manuals, but I'm just not finding it. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Re: LH + MVC
Well said, John. Mocking is not a good teaching method. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 john gilmore wrote (snipped): I indeed think that mistakes of this kind at an early stage in learning a language are characteristic of intelligent learners. They need to be corrected, gently and in circumstantial detail; but laughing at them is both provincial and counter-productive.
Re: CDS and alignment question
From z/Architecture Principles of Operation: The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. The second operand of COMPARE AND SWAP (CSG) and COMPARE DOUBLE AND SWAP (CDS, CDSY) must be designated on a doubleword boundary. The second operand of COMPARE DOUBLE AND SWAP (CDSG) must be designated on a quadword boundary. The R1 and R3 fields for COMPARE DOUBLE AND SWAP must each designate an even-numbered register. Otherwise, a specification exception is recognized. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Mark Hammack wrote: Thanks for all of the suggestions! Of course, one fundamental question that the discussion has prompted in my mind is: Why does the data for a CDS need to be on a doubleword anyway? The data is read from or loaded into the low order 32 bits of two consecutive registers. As such, it seems that the data is really two consecutive fullwords, not a doubleword. Using STGHEAD-STGPOOL(R5) is a good idea unless and until I need to change base registers, in which case, I have to remember to change the instruction. Better, but not ideal IMO. To answer the (first) original question, I guess HLASM doesn't look at hardcoded offsets, just generated base/offset (S-con). I am still not sure whether the actual data MUST be on a true doubleword boundary or if it would work on a fullword boundary. Guess it's time for an experiment. Thanks again, Mark Hammack Senior Technical Specialist Systemware, Inc. On Tue, Aug 17, 2010 at 1:27 PM, Schwarz, Barry A barry.a.schw...@boeing.com wrote: If you expect STGHEAD to always be double word aligned and R5 to always contain the address of an odd word, you need a way to inform the assembler you are violating conventional alignment. One possible method is STGXXX DSECT DSF STGPOOL DS0X STGSIZE DSF STGHEAD DSA ... which has the advantage of not requiring any changes to your USING statements. All of which begs the question of why STGHEAD is DS A and not DS D. Or at least preceded by a DS 0D. If updating the DSECT is impractical at this time, you can still eliminate the hardcoded offset by using STGHEAD-STGPOOL in place of 4. Your code will be self adjusting if the DSECT ever does change. -Original Message- From: IBM Mainframe Assembler List [mailto:assembler-l...@listserv.uga.edu] On Behalf Of Mark Hammack Sent: Tuesday, August 17, 2010 7:33 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: CDS and alignment question Yes, STGHEAD is in a DSECT: STGPOOL DSECT STGSIZE DS F STGHEAD DS A STGCNTDS F STGERRDSF As I said in the original e-mail, the easy thing to do would be to rearrange the dsect so that STGHEAD is on a doubleword boundary (i.e. move STGERR before STGHEAD and add DS 0D before the actual data). However, finding all of the procedures that rely on this particular layout may be difficult. But I will be changing it in a future release of the software. My other option is to 'go back' to hardcoded offsets (i.e. 4(R5) ) since HLASM doesn't complain about that) and document why things are done the way they are (forcing the pool definition to a 'doubleword+4' boundary so that STGHEAD is on a doubleword for example which was another interesting exercise and exactly what 4(R5) is).
