Re: Subject: Re: Currency format suggestions, please?
Fair point. When I was at school we used "billion" as long scale 10^12, but by the time I worked for Nasty Wetmonster Bank it was short scale. I tend to just say "thousand million" :-) Roops On Sun, 2 Apr 2023, 00:34 Gary Weinhold, wrote: > This is been very interesting, but no one has mentioned billions and > trillions. When I was a young, I learned that the UK million was the same > as US, but billion was a million millions (not just a thousand million) and > a trillion was a million billions and so on. i guess It makes a difference > when you're talking about national debt (cue Senator Everett Dirksen). > Anyway, UK switched to the thousands- based 'illions in 1974. > > Gary Weinhold > Senior Application Architect > DATAKINETICS | Data Performance & Optimization > Phone:+1.613.523.5500 x216 > Email: weinh...@dkl.com > Visit us online at www.DKL.com > 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. > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding DU-AL in a dump
Actually it’s a task The dataspace is owned by another address Space I’m thing of writting a customized TESTAUTH subcommand to display it im begging to realize I’ll have to pass the stoken to do it Thanks > On Apr 1, 2023, at 8:43 AM, Peter Relson wrote: > > In one of the appends there was talk about an SRB. So which is it? SRB or > task? > > Whether valid or not, from one work unit (SRB or task) you cannot use another > work unit's DU-AL ALET. Only PASN-AL ALETs and common area data space (CADS) > ALETs can be used from multiple work units. > > If looking around in a dump is useful, have at it. Obviously the SRB's DU-AL > is not going to be by locatable by some task's STCBALOV. > If the SRB is represented by an SSRB, its DU-AL can be found in SSRXALOV > where the SSRX can be found via 64-bit pointer SSRBSSRX. > > The system trace, if you can capture that in a dump, for your SRB will show > its WEB address (for a task it shows the TCB address). > WEBTYPE can tell you if it's an SRB or SSRB. For an SSRB, WEBUPTR points to > the SSRB. > > This is diagnostic information, not a programming interface. > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RTM/SDWA question
Thanks That’s what I thought In order for my recovery to do a retry My register have to be in tact R3 is the base for all my csects 4 bytes off that is my eyecatcher as I branch round that comparing R3 + 4 for the eyecatcher is how I determine that I start SDWAGR then I try SDWASR Then I try the rbregs I preface everything with a TPROT If everything fails I percolate For 2 out 3 there 64 bit registers Thanks > On Apr 1, 2023, at 8:12 AM, Peter Relson wrote: > > > Are the registers at SDWASR00 the same as the registers pointed to by > SDWARBAD when SDWARBAD is around I have noticed most of the time they are > > > Your words of "most of the time" indicate that you have observed that they > are not always. > Your observation is correct. Sometimes yes, sometimes no. Read the comment on > the field. > And the RB in which the error occurred is not necessarily the RB that created > the recovery routine. > > There is very limited diagnostic use of that data, so we did not feel it > necessary to spend storage space in the SDWA to provide the 64-bit high > halves or 16-byte psw. > > Peter > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Subject: Re: Currency format suggestions, please?
This is been very interesting, but no one has mentioned billions and trillions. When I was a young, I learned that the UK million was the same as US, but billion was a million millions (not just a thousand million) and a trillion was a million billions and so on. i guess It makes a difference when you're talking about national debt (cue Senator Everett Dirksen). Anyway, UK switched to the thousands- based 'illions in 1974. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASM call by value
On Sat, 1 Apr 2023 13:34:02 +, Peter Relson wrote: >... One is to make a copy and pass the argument by reference to the copy. > Another is to pass the actual value (somewhere, somehow). > ??? "somehow". The mechanism of passing an "actual value" distinct from a copy is left as an exercise for the student's imagination. >... Or make your own copy. > A third option for languages providing a syntactic distinction between "reference" and "value" is that the caller could pass a reference and entry code in the called routine could transparently make a copy. This should provide "value" semantics, except for a few race conditions, with the advantage that the code to copy exists once in the entry rather than at each point of call. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASM call by value
I was taught long ago that "call by value" meant simply that whatever the target routine did to a parameter was not reflected back to the caller's argument. There are multiple possible implementations. One is to make a copy and pass the argument by reference to the copy. Another is to pass the actual value (somewhere, somehow). For what it's worth, the internal PL/X that much of z/OS is written in only supports call by value for the cases where the argument fits within the "width" of a parameter list entry (by convention, 4-bytes for an AMODE 31 call, 8-bytes for an AMODE 64 call). PL/X's "call by value" never copies (accompanied by passing the copy by reference). We have many places where our dynamic storage is strictly limited such that "copy" is often not a possibility. So what happens if you have something larger than fits but don't want it changed? Too bad. Or make your own copy. The interface definition shared by the source and target identifies whether the parameter is to be treated as input-only or not. It is up to the compiler to help identify places where the target code writes into something that is input-only and passed by reference. That does not make this implementation "good" or "bad". Probably it's "good" in some ways, "bad" in others. It is what it is. An interesting facet of this comes when passing an ALET (so that your argument can be addressed by its address and its ALET). In effect, the ALET really has to be passed not by reference in any way because otherwise you would have no way of identifying how to access the ALET and would have to have some rule/restriction about where that could live (maybe you can live with such a restriction, perhaps that the ALET must be in the primary address space; maybe you can't). So you pass the ALET by placing it in a parameter list slot where it is accessible according to the rules of how to access the parameter list (generally R1 and, if in AR mode, AR1). In some cases you can consider the "ALET and address" as occupying two slots in the parameter list, but in others you might want to take advantage of passing "one ALET" with the "knowledge" (AKA restriction) that multiple parameters are in the space identified by that single ALET . In restrictive cases you can pass something byvalue in a register (but that does not scale well). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: finding DU-AL in a dump
In one of the appends there was talk about an SRB. So which is it? SRB or task? Whether valid or not, from one work unit (SRB or task) you cannot use another work unit's DU-AL ALET. Only PASN-AL ALETs and common area data space (CADS) ALETs can be used from multiple work units. If looking around in a dump is useful, have at it. Obviously the SRB's DU-AL is not going to be by locatable by some task's STCBALOV. If the SRB is represented by an SSRB, its DU-AL can be found in SSRXALOV where the SSRX can be found via 64-bit pointer SSRBSSRX. The system trace, if you can capture that in a dump, for your SRB will show its WEB address (for a task it shows the TCB address). WEBTYPE can tell you if it's an SRB or SSRB. For an SSRB, WEBUPTR points to the SSRB. This is diagnostic information, not a programming interface. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RTM/SDWA question
Are the registers at SDWASR00 the same as the registers pointed to by SDWARBAD when SDWARBAD is around I have noticed most of the time they are Your words of "most of the time" indicate that you have observed that they are not always. Your observation is correct. Sometimes yes, sometimes no. Read the comment on the field. And the RB in which the error occurred is not necessarily the RB that created the recovery routine. There is very limited diagnostic use of that data, so we did not feel it necessary to spend storage space in the SDWA to provide the 64-bit high halves or 16-byte psw. Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CASE constructs
On Sat, 1 Apr 2023 11:30:24 +0100, Rupert Reynolds wrote: >... >while in COBOL people were using ALTER with GOTO (oof!). > ??? But didn't they need a CASE/SELECT to choose which ALTER? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CASE constructs
I seem to remember that most of the perceived weaknesses in COBOL were addressed a long time ago. But some old tales just won't die. Back when JSP meant Jackson Structured, I remember being told that PL/I supported selection directly with 'SELECT', while in COBOL people were using ALTER with GOTO (oof!). It may have been true, briefly, but it seems COBOL caught up in most respects reasonably quickly. Roops On Sat, 1 Apr 2023, 02:24 Frank Swarbrick, wrote: > COBOL: > > EVALUATE A = 1 > WHEN TRUE [...] > WHEN FALSE [...] > END-EVALUATE > > (WHEN FALSE could be WHEN OTHER in this case.) > > Not many people would use this over IF ELSE, but it's available. > > There's also "EVALUATE TRUE" where each WHEN is a full evaluation, > eliminating any need for IF ELSE/IF ELSE/IF ELSE. > > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
