Re: Edit Masks
That would work. However, unless you're planning to have decimal positions later or change between leading zeros and leading blanks, you can drop ED and the mask and just use UNPK. Using ED in your case is just making more work for yourself. OREXXMan Q: What do you call the residence of the ungulate with the largest antlers? A: A moose pad. :-D Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. REXX is the new C. On Thu, Mar 10, 2022 at 8:47 AM Dave Clark wrote: > If I have a 3-byte packed decimal field (and let's say 0 decimals > for simplicity), I might normally go with the following edit mask if I > didn't want to retain leading zeros but leave one zero for a value of > zero. > > x'40202020212060' > > But if I wanted to retain leading zeros, would you simply change > the fill byte to x'F0'? ...or would you do something else? > > Sincerely, > > Dave Clark > -- > int.ext: 91078 > direct: (937) 531-6378 > home: (937) 751-3300 > > Winsupply Group Services > 3110 Kettering Boulevard > Dayton, Ohio 45439 USA > (937) 294-5331 > > > > > * > This email message and any attachments is for use only by the named > addressee(s) and may contain confidential, privileged and/or proprietary > information. If you have received this message in error, please > immediately notify the sender and delete and destroy the message and all > copies. All unauthorized direct or indirect use or disclosure of this > message is strictly prohibited. No right to confidentiality or privilege > is waived or lost by any error in transmission. > > * >
Re: Base-less macros
This draft document, entitled Register Constraint Relief 2021, coincidentally addresses the subject of Base-less/Base-free Macros. See references to Base Address Register (BAR) 15 and relative addressing for all base/displacement operands.. https://docs.google.com/document/d/19O8Z-H3XcgiDWOI_zO4NM8JnRHllGn91sFTDtgQ39bc/edit?usp=sharing OREXXMan Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. REXX is the new C. On Wed, Nov 10, 2021 at 3:02 AM Jonathan Scott wrote: > The documentation update for APAR PH34824, for the alignment of > literals referenced by relative address, has now been completed. > > https://www.ibm.com/docs/en/hla-and-tf/1.6?topic=instruction-literal-pool > > It seems it was overlooked after being transferred from our old > request tool to the new - a case of "falling between two tools". > > Jonathan Scott, HLASM > IBM Hursley, UK >
Re: EQU * considered harmful
I think we are missing some points here. If you put a label on an instruction, the symbol is defined with the correct length (2, 4, or 6), and a type of C'I'. Unless and until there is a MACRO that does this, I can't endorse either DS 0H or EQU *; use structured macros instead. OREXXMan JCL is the buggy whip of 21st century computing. Stabilize it. Put Pipelines in the z/OS base. Would you rather process data one character at a time (Unix/C style), or one record at a time? IBM has been looking for an HLL for program products; REXX is that language. On Thu, Aug 2, 2018 at 4:29 PM Steve Thompson wrote: > On 08/02/2018 04:09 PM, Paul Gilmartin wrote: > > On 2018-08-02, at 14:00:37, Steve Thompson wrote: > >> > >> I haven't touched a Univac since 1979. So I forgot a few things. But > still, the 36 bit words made it a pain for communicating with a DEC. I was > asked how to get them to talk to each other... It was interesting -- > thankfully I kept doing FORTRAN-77 and someone else built the interface box. > >> > > "If you don't have 36-bit words, you're not playing with a full DEC!" > > > > PDP-6, decsystem-10 and decsystem-20 had 36 bits. Vax broke the mold. > > > > -- gil > > > It was NASA. They were using old equipment. I don't remember > which DEC boxes they had, I was told that the I/O interface was > 16bits wide. > > But, the Space Shuttle flew in spite of the fun we had writing > the ground support software. -- Goddard Space Flight, Beltsville MD > > Regards, > Steve Thompson >
Re: An idea I got when researching a bug - warnings when a specific register is changed
Phil. I went to Cornell, where PL/C was developed. In my freshman class, anyone who already knew a programming language (I knew 3 then) was given work in PL/1 (as then called), using PL/C, instead of in FORTRAN. I think we were one of the first classes, if not the very first, to beta test it. Being skeptical of compiler output has been a helpful skill ever since. Where did you use PL/C? OREXXMan JCL is the buggy whip of 21st century computing. Stabilize it. Put Pipelines in the z/OS base. Would you rather process data one character at a time (Unix/C style), or one record at a time? IBM has been looking for an HLL for program products; REXX is that language. On Thu, Jun 28, 2018 at 4:23 PM, Phil Smith III wrote: > Hobart Spitz wrote: > >the latter..., or something even milder, I just don't know what. Getting > >into the habit of ignoring warnings is not a great idea, and it means > >questions for the next person that has to look at your code. > > Thanks for taking my point as intended, sir. Always risky these days...! > > Absolutely, ignoring warnings is a Very Bad Habit. My first official > (computing) language was PL/I (well, PL/C): I sat in on my dad's university > course the summer of 1975, after my 8th grade. He taught me to examine and > hopefully eliminate any warnings. At the time, I thought PL/I was anal > about such things; now that I have to deal with C, I long for PL/I. I feel > like in C there are lots of warnings that "everybody ignores" (often by > telling the compiler not to issue them), whereas in PL/I I don't recall > being unable to eliminate every one of them legitimately. > > I like the idea of PROTECT/UNPROT instructions*. Seems like the cleanest > way to do it to me. > > So, we'll have this later this year, right? :) > > ...phsiii > > *I wasn't sure of the right term for "a thing that the assembler looks at > but doesn't actually generate code"; Google found me IBM pages that refer > to USING as an "instruction", so I would take PROTECT/UNPROT to be in the > same category. Happy to be corrected, as ever. >
Re: An idea I got when researching a bug - warnings when a specific register is changed
Phil, > Seriously, not picking a fight, just don't understand whether you're saying "This doesn't work because" or "Note that in cases like this, there'd be some tinkering"? the latter..., or something even milder, I just don't know what. Getting into the habit of ignoring warnings is not a great idea, and it means questions for the next person that has to look at your code. I like the general idea. AKAIK, there is an EQU feature that checks that you are using the right size register (32 or 64 bit) with the right instruction. Perhaps something similar would do the trick. Or maybe just a macro, like: macro lbase , Load a USING base reg unprot l , protect mend OREXXMan JCL is the buggy whip of 21st century computing. Stabilize it. Put Pipelines in the z/OS base. Would you rather process data one character at a time (Unix/C style), or one record at a time? IBM has been looking for an HLL for program products; REXX is that language. On Thu, Jun 28, 2018 at 10:22 AM, Phil Smith III wrote: > Hobart Spitz wrote: > >If you are traversing a linked-list of control blocks (e.g.), you might > >validly modify a USING register that points to a DSECT of that control > >block. > > Sure, but...so? You'd explicitly unprotect, change, reprotect. That's the > whole point. (Or not protect at all; this is optional, after all.) > > Seriously, not picking a fight, just don't understand whether you're > saying "This doesn't work because" or "Note that in cases like this, > there'd be some tinkering"? >
Re: An idea I got when researching a bug - warnings when a specific register is changed
On 25 June 2018 at 21:49, Phil Smith III wrote: > > Seriously, l like it and would use it. I'd prefer it not be tied to USING > because there are other reasons to not use a register (I think; can't come > up with any offhand, but I feel like there are?). Maybe: If you are traversing a linked-list of control blocks (e.g.), you might validly modify a USING register that points to a DSECT of that control block. OREXXMan JCL is the buggy whip of 21st century computing. Stabilize it. Put Pipelines in the z/OS base. Would you rather process data one character at a time (Unix/C style), or one record at a time? IBM has been looking for an HLL for program products; REXX is that language. On Mon, Jun 25, 2018 at 4:11 PM, Rob van der Heij wrote: > On 25 June 2018 at 21:49, Phil Smith III wrote: > > > > > Seriously, l like it and would use it. I'd prefer it not be tied to USING > > because there are other reasons to not use a register (I think; can't > come > > up with any offhand, but I feel like there are?). Maybe: > > > > I suppose there are plenty of cases outside the USING where it is harmful > to modify a register. Don't forget the base register, for those who don't > write baseless yet. And reading the value from the wrong register can also > keep you entertained for a while. I find these bugs mostly get in when I go > back and change the original choice of registers because it appears handy > to pick another one. > > Quite often the USING remains valid but the register points to another > object. I can see how you would put the USING and DROP within the loop when > the pointer is incremented. When you're picking up the next pointer from a > chain, you end up having to quality the field outside the USING scope > again. If anything, I would want tie this to the static nesting scope or > block structure rather than manually having to free up the protection. > > Instead of having this done during assembly, you could also have it as a > post-processing on the LISTING or ADATA. I inherited something that goes > through the assembly listing and frowns at known concerns.Personally, I > don't think this one is highest on my facepalm list. > > Rob >
Re: CamelCase (was: ASSEMBLER-LIST Digest ...)
I think this discussion needs to distinguish clearly between case-sensitive (treating caps and lower case the same) and case-insensitive (treating the upper and lower case of the same character as different). Mixed-case could mean either, and is therefore unclear. IMHO, case-insensitivity is not human-friendly. I can't think of any reason to use it, but no doubt someone has, On Fri, Feb 28, 2014 at 9:52 AM, Paul Gilmartin paulgboul...@aim.comwrote: On 2014-02-25, at 10:00, John Walker wrote: So, to respond to the one comment, it was ok for the Science guys to want mixed case things because that was what they were used to. Ok, I can buy that. Same rationale can be applied to the C programmers. Now, let's be fair, using the very same reasoning, I can then justify MY perception that mixed case shouldn't be used on the mainframe, because I am used to it. Now, if you say they can justify their actions out of their preferrences and I can NOT do the same thing, then you surely can see how that is not fair for everyone, right? Let's see. The monocase enthusiasts have JCL as they like it. The mixed case enthuiasts have C as they like it. All within the z/OS environment. Something for everyone. Sounds like a compromise; everyone should be happy. You sound bitter; intolerant. Would you stop the science guys at the border because they speak a different language? Why did you write your messave in mixed case? It's probably OK as long as you didn't compose it on a mainframe. -- gil -- OREXXMan
Re: Use of sequence numbering in current HLASM source?
There are some reasons, albeit llittle known, to keep line numbers: 1. With STATS and NUM on, ISPF edit stores the edit session number in 79-80. It's the same as the MM of VV.MM column in the ISPF member list. This information is useful in edit, browse, and compiler/assembly listings. 2. With the default increment, listings (whether printed or on DASD) are still useful even after modest changes. Anything that preserves information and/or promotes productivity is a good thing. On the down-side, the ISPF edit locate (L) command can't be used with the line numbers in messages. So I use an edit macro that I call LL. This is a bare-bones version: /* REXX */ address isredit macro (LinCount) up max down LinCount return 0 Also on the down-side, you loose some potential source code real estate. Unless you are using a 3278-5 (132x27emulation configuration), and have the right ISPF terminal settings, this is no big loss. Most people choose not to scroll left and right to use that area on 80 column emulation. On Wed, Nov 7, 2012 at 2:15 PM, McKown, John john.mck...@healthmarkets.comwrote: So, in summary, use them or not as the individual or company dictates. I don't really lose any capability by keeping my source as I do, without sequence numbers. Thanks to all. It was interesting to read that some still do have a use for these. -- 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.comhttp://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 -- OREXXMan
Re: Detecting RMODE at assembly time
For one thing, if a page has not been modified since it was paged in, and it's slot on backing store has not been reused, it can be assigned to another address space without first writing it to disk. I believe this is called page-stealing. On Mon, Jul 2, 2012 at 10:14 AM, Edward Jaffe edja...@phoenixsoftware.comwrote: On 7/1/2012 7:03 PM, Alex Kodat wrote: Sorry but I don't understand what re-entrancy has to do with how storage is backed. Care to explain? I was referring to the practice of using GETMAIN to acquire working storage areas. This technique is most often employed by RENT programs. Also, I assume by have no control over the backing of storage you meant that most older programs don't specify the required backing for their GETMAIN? No. I meant that programs don't have control over where the storage, into which they are loaded by the contents supervisor, is backed. -- 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/ http://www.phoenixsoftware.com/ -- OREXXMan
Re: Detecting RMODE at assembly time
Thanks for the corrections. On Mon, Jul 2, 2012 at 2:29 PM, John Gilmore jwgli...@gmail.com wrote: As Tom Marchant has already pointed out, Hobart Spitz's view of page stealing is mistaken. Perhaps even more important his view of how the ASM [Auxiliary Storage Manager] works is also mistaken. No page that has not been modified is paged out. (One of the minor but important merits of reentrant coding is/was that by segregating never paged-out code pages and frequently paged-out data pages it reduces paging overheads significantly.) His post did have the virtue of reviving the [predominantly British] term 'backing store' which has always seemed to be to be a very good, self-descriptive one, the wider of which is now unfortunately all but precluded by other, different and preemptive, uses of the too similar term 'backing storage'. John Gilmore, Ashland, MA 01721 - USA -- OREXXMan
Re: Base registers
Just my two cents: 1. There are architectures which have always had relative addressing, and use that term. 2. Some day, relative braches will be the norm and not the exception. As time goes on, any term with base as the root (e.g. unbased, baseless, etc.) is likely to need increasingly superfluous explanations to novices. Thus, I suggest relative branch and/or jump should suffice. For the exclusive case (non-base register branching) perhaps relative-only branching and/or jump-only program[ming]. On Sun, Jun 17, 2012 at 5:38 PM, J R jayare...@hotmail.com wrote: Sorry Steve. I didn't see your post until after I posted mine. === Date: Sun, 17 Jun 2012 17:35:36 -0400 From: jayare...@hotmail.com Subject: Re: Base registers To: ASSEMBLER-LIST@LISTSERV.UGA.EDU The problem is that all addresses are relative to something. Some are relative to a base register, some are relative to the current instruction. Even absolute addresses are relative to zero. ;-) How about base-free code? That sounds like a positive thing. (I avoided the temptation to to suggest freebase lest that be considered to have a negative connotation.) === Date: Sun, 17 Jun 2012 17:13:30 -0400 From: gt.ibm.li...@actionsoftware.com Subject: Re: Base registers To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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 -- OREXXMan
Re: Assembler info needed
I wouldn't even bother with S/370. Start at S/360. You don't care about paging or vitual storage, yet. Once you have the S/360 down, most architectural extensions generalize easily from there. PoOps is way too much for a beginner, both in volume and prerequisite knowledge. In the '60s, Tim Tomaselli of Stevens gave me an IBM publication. Little did he know how valuable it would turn out to be. Thank you, Tim!! It was excellent. You can find it here: http://www.bitsavers.org/pdf/ibm/360/training/C20-1646-1_A_Programmers_Introduction_To_IBM_System360_Assembler_Language_May66.pdf On Fri, Mar 16, 2012 at 2:47 PM, Tony Harminc t...@harminc.com wrote: On 16 March 2012 11:49, Farley, Peter x23353 peter.far...@broadridge.com wrote: The other prerequisite to learning assembler is understanding the basic architecture of the machine. For this knowledge you will eventually need to read at least parts of the z/Architecture Principles of Operations manual (available on the IBM website). This is a very large and imposing manual that can seem overwhelming at first (and still is even when you are an expert). Chapters 1 through 6 would enable you to gain a serious understanding of the z/Architecture machines, but they do contain very dense material to absorb all at once. Alternatively, you can use chapter 7 in conjunction with reviewing the COBOL listing output I mentioned above to see what each instruction does. This may provide a simpler introduction for you. Another less overwhelming approach to the Principles of Operation is to look at a much older one, such as the S/370 version GA22-7000 (but not the -00 version!) available on bitsavers.org and many other sites. There is nothing in the discussion of general instructions in such an old book that is obsolete; they will all work nicely on the latest hardware. Tony H. -- OREXXMan
Re: alternatives
Just my two cents: Preface: A change control/configuration management system usually automates existing policies and procedures for software deployment. They tend to vary wildly from installation to installation. Off the shelf products have difficulty handling all the specific needs of a particular site: Cost-effective compromises have to be made. My experiences: I have been in five sites where they wrote their own systems. In all cases, the results were satisfactory, full-functioned, right-sized, cost-effective and still in use last I heard. In two cases, I participated in the initial design, implementation, and on-going support; in two others, in enhancement, maintenance and support. At one site, it took the team 1 day to define the requirements and design the command-level interface, a second day to code the core functions, and a week to implement the basic web-based developer interface. Subsequent enhancement, support and maintenance took about a staff-week per year. Conclusions: - Consider the costs and benefits of designing and writing your own change control/configuration management system. - Use an open ended design, with a command line accessible core. - Use a release methodology (per Gartner Group and my experiences): Piecemeal (AKA emergency) deployments mean untested configurations in production . YMMV On Thu, Feb 16, 2012 at 12:53 PM, Ron Wells ron.we...@slfs.com wrote: Looking for alternatives to CHANGEMAN any suggestions to Look at..?? Pro's/Con's -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. -- OREXXMan
Re: Assistive Technology
Stan; Thanks for bringing this up. I'm sure that those who are in a position to address this will do so promptly. We can expect no less. - Hobart On Fri, Dec 9, 2011 at 8:05 AM, Gowin, Stan stan.go...@softwareag.comwrote: Hi, I know your remark was intended to be mildly humorous and it was. However, as a long-time blind assembler programmer I must point out that assistive technology is key to my ability to do my job. Most of the time this means software on my PC that magnifies or speaks items on the screen in an intelligent manner so that I can program and debug those programs. Where this intersects with the assembler list is the accessibility of the documentation provided by IBM and vendors to support coding and products running on the mainframe. I'm afraid as the proliferation of the web and the use of PDF files has come to dominate the way technical documentation is distributed, the accessibility of said documentation has suffered. The old 16-bit Book Manager Read product for Windows was the most efficient and best organized way for me to use IBM documentation. The new Java version of the Book manager product is virtually inaccessible to the blind and using PDF files or the web is acceptable but I very much wish that IBM would make an accessible version of the Book manager Read product that can run on a Windows 7 64-bit PC. So, there are still challenges for the blind or otherwise disabled mainframe computer programmer which is a shame in this modern era where so many opportunities exist for persons with accessibility needs to acquire and use information needed to work productively. Regards, Stan Gowin Software Ag -- OREXXMan
