Re: Goodbye, thanks, and take care!
Peter Many times you have helped. Best wishes and enjoy your retirement On Mon, 28 Jan, 2019, 11:01 AM Peter Hunkeler I will retire by the end of the month. > > > Thank you so much for all the help, and for all the bearing with me. I > learnt a hell lot just by following this and other fora. Quite often I was > able to solve problems based on the help and the advice given by you. > > > I wish you good health and much fun. > > > Goodbye > Peter > > > -- > Peter Hunkeler > > -- > 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
Goodbye, thanks, and take care!
I will retire by the end of the month. Thank you so much for all the help, and for all the bearing with me. I learnt a hell lot just by following this and other fora. Quite often I was able to solve problems based on the help and the advice given by you. I wish you good health and much fun. Goodbye Peter -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IARV64 - why ABEND rather than return with reason code?
> > For private storage (and also for common storage when > >common storage tracking is not turned on), VSM does not > >keep track of the size of the original request. Two > >separate GETMAINs which end up being adjacent are > >indistinguishable from one GETMAIN for the sum of the > >sizes. > > > I hope no programmer counts on that. But I suspect some do > and that was among the motivations for a compatibility option > when the storage management scheme changed radically a few > releases ago. > > --gil You suspicion would be incorrect. As the designer and implementer or those changes, I would not call them radical. However, even a minor change in storage management has the potential to expose latent bugs, so I included an undocumented DIAGxx TRAP to revert to prior behavior as a bypass if needed. One of the ESP customers for the release hit such a bug in a key 0 program, which had severe consequences. They insisted that we should make the prior behavior the default, with a documented option to request new behavior. Although that was not what we wanted to do, we also did not the risk of an ESP customer giving a Share presentation about a bad migration experience due to IBM's intransigence, so we gave in and did as they requested. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSAFF and SCHENV
I used SCHENV several years ago to direct workload to a CEC that had a ZIIP installed. Another use is for EXCI - switch the SCHENV on and off according to the availability of the CICS region. On Mon, 28 Jan 2019 at 06:26, Jesse 1 Robinson wrote: > Before we implemented SCHENV control, we depended on SYSAFF to direct a > job toward the member running a suitable Db2 subsystem. Then we had a > couple of instances where the target Db2 abended and would not restart on > the 'normal' LPAR, but would run a different LPAR. The task of directing a > slew of batch jobs containing SYSAFF to another LPAR was laborious and time > consuming. Or else IPL. > > With SCHENV, we could issue a few WLM commands to disable resources on the > broken LPAR and enable them on the other one. No change to automation, no > change to JCL. And most all, no unscheduled IPL. > > However, SCHENV would not (early 2000s) override SYSAFF. If SYSAFF and > SCHENV conflicted, a job would just hang. So part of the supporting SCHENV > code was to nullify any SYSAFF if SCHENV was also specified. If that has > changed, we never revisited the issue. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Anthony Hirst > Sent: Sunday, January 27, 2019 4:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: SYSAFF and SCHENV > > One difference that I haven't seen be mentioned is that SYSAFF controls > all stages of JES2 processing, while the SCHED only controls execution > phase, we've run into issues where subsystems aren't active on some LPARs > and a job with a SCHED setting gets interpreted on that system you get a > JCL error, only way to avoid that we've found is to code SYSAFF. We keep > the SCHED to because it points to the actual resource requirement adding > documentation. > > On Sat, Jan 26, 2019 at 8:53 PM Peter wrote: > > > Hi > > > > It is just general question > > > > I was going through the manual. > > > > Does SCHENV perform the same function as SYSAFF ? Or it does more than > > that ? > > > > Peter > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Mike Shorkend m...@shorkend.com www.shorkend.com Tel: +972524208743 Fax: +97239772196 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IARV64 - why ABEND rather than return with reason code?
On Sun, 27 Jan 2019 23:47:09 -0500, Jim Mulder wrote: > >> If I were designing >> FREEMAIN from scratch, I would drop the LENGTH and just always free >> the entire block. Yes, you would lose the ability to free half of a >> buffer -- but gain some simplicity of design, and eliminate the >> nasty bug where you free all but 8 bytes of some repeatedly-obtained >> area, and never notice it until some customer runs out of (contiguous) >> memory. > OMG! A severe case of HLL-think! (But no garbage collection.) Many years ago, I witnessed several assembler programmers being dragged unwittingly, often unwillingly into a HLL environment. Chief complaints were: o No facility to increment a pointer. o No facility to do a single new(); subdivide the block; and dispose() piecemeal. > For private storage (and also for common storage when >common storage tracking is not turned on), VSM does not >keep track of the size of the original request. Two >separate GETMAINs which end up being adjacent are >indistinguishable from one GETMAIN for the sum of the >sizes. > I hope no programmer counts on that. But I suspect some do and that was among the motivations for a compatibility option when the storage management scheme changed radically a few releases ago. --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IARV64 - why ABEND rather than return with reason code?
> For the past ten years I have been developing z/OS "system" software > primarily in C++. I have become a big believer. I like the > productivity -- I think I can write more end-user functionality in a > day than an assembler programmer. I like the avoidance of low-level > errors -- "oh crap, I forgot that routine needed R2." I like the > incredibly optimized object code produced by the compiler. I like > the design that emerges from object-oriented thinking. > > One of the side effects of developing in C++ is an end to reliance > on dumps as a primary debugging tool. One, the machine code produced > by the C++ compiler is often inscrutable. That's why I have been heard to say in IBM, "If you wrote it in C, you must have wanted to debug the problems yourself". We have spend a lot of effort with the PL/S-PL/AS-PL/X family of compilers to make the assembler (not machine) code code produced by the compiler as understandable as possible, because we know that we are going to have to debug a lot of low-level operating system problems from dumps. Also, since the compiler generates an assembler source file which is subsequently assembled, the facilities for including inline assembler code are far better than in C. Also, interoperability with assembler code was one of the primary design objectives from the beginning, so of course it is going to far better than in other languages where that was not the case. It is unfortunate that IBM does not make PL/X (which has object-oriented capabilities) available to ISVs. I have often wondered why the large ISVs did not have their executives constantly hammering IBM executives over this issue. Of course, in the older days when IBM viewed ISVs as evil competitors and PL/xxx as a competitive advantage, this would have been a nonstarter. In later years when IBM started to see ISVs as an important part of the mainframe ecosystem, things might have been different (and almost were - we came pretty close to making PL/X available one time years ago, before some IBM executive squelched it). > To your point about EXECUTABLE=YES, I have always thought that > FREEMAIN required too many details. If MVS is to free the storage, > what difference does it make if it is executable or not? The address > is unique -- why must the subpool be specified? You can blame me for that EXECUTABLE requirement on FREEMAIN. Internally, we implement EXECUTABLE=YES/NO like two separate subpools (for each subpool, there are separate SPQEs for EXECUTABLE=YES and EXECUTABLE=NO). In the interest of minimizing the implementation costs for a project that was being done on a tight schedule, I recommended the requiring a correct EXECUTABLE specification when freeing storage. It would still be possible enhance this in the future by treating the EXECUTABLE specification as a performance hint which says which SPQE's DQE chains to search first, and then do the other SPQE next if not found in the first. As always, if you feel strongly about that, submitting an RFE may help your chances. > If I were designing > FREEMAIN from scratch, I would drop the LENGTH and just always free > the entire block. Yes, you would lose the ability to free half of a > buffer -- but gain some simplicity of design, and eliminate the > nasty bug where you free all but 8 bytes of some repeatedly-obtained > area, and never notice it until some customer runs out of (contiguous) memory. For private storage (and also for common storage when common storage tracking is not turned on), VSM does not keep track of the size of the original request. Two separate GETMAINs which end up being adjacent are indistinguishable from one GETMAIN for the sum of the sizes. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSAFF and SCHENV
Before we implemented SCHENV control, we depended on SYSAFF to direct a job toward the member running a suitable Db2 subsystem. Then we had a couple of instances where the target Db2 abended and would not restart on the 'normal' LPAR, but would run a different LPAR. The task of directing a slew of batch jobs containing SYSAFF to another LPAR was laborious and time consuming. Or else IPL. With SCHENV, we could issue a few WLM commands to disable resources on the broken LPAR and enable them on the other one. No change to automation, no change to JCL. And most all, no unscheduled IPL. However, SCHENV would not (early 2000s) override SYSAFF. If SYSAFF and SCHENV conflicted, a job would just hang. So part of the supporting SCHENV code was to nullify any SYSAFF if SCHENV was also specified. If that has changed, we never revisited the issue. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Anthony Hirst Sent: Sunday, January 27, 2019 4:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: SYSAFF and SCHENV One difference that I haven't seen be mentioned is that SYSAFF controls all stages of JES2 processing, while the SCHED only controls execution phase, we've run into issues where subsystems aren't active on some LPARs and a job with a SCHED setting gets interpreted on that system you get a JCL error, only way to avoid that we've found is to code SYSAFF. We keep the SCHED to because it points to the actual resource requirement adding documentation. On Sat, Jan 26, 2019 at 8:53 PM Peter wrote: > Hi > > It is just general question > > I was going through the manual. > > Does SCHENV perform the same function as SYSAFF ? Or it does more than > that ? > > Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Red Hat (was Re: how many OSes run on IBMz)
On 1/25/2019 2:39 PM, Gord Tomlin wrote: It will be a great opportunity for IBM to show whether it genuinely supports the open source community. If you have any doubt on /that /score, you should check out IBM i and IBM Q. Of all the Great Beasts on the Block, IBM has over the decades played the most fairly with the open source community, period. -- Jack J. Woehr # Science is more than a body of knowledge. It's a way of www.well.com/~jax # thinking, a way of skeptically interrogating the universe www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Subject: Re: [EXTERNAL] Re: how many OSes run on IBMz
On Sun, 27 Jan 2019 21:23:32 +, Seymour J Metz wrote: >For the same reason that Nova (No va) is funny in Hispanic countries; BS has a >colloquial meaning in the US. > That's disputed: https://www.snopes.com/fact-check/chevrolet-nova-name-spanish/ -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSAFF and SCHENV
One difference that I haven't seen be mentioned is that SYSAFF controls all stages of JES2 processing, while the SCHED only controls execution phase, we've run into issues where subsystems aren't active on some LPARs and a job with a SCHED setting gets interpreted on that system you get a JCL error, only way to avoid that we've found is to code SYSAFF. We keep the SCHED to because it points to the actual resource requirement adding documentation. On Sat, Jan 26, 2019 at 8:53 PM Peter wrote: > Hi > > It is just general question > > I was going through the manual. > > Does SCHENV perform the same function as SYSAFF ? Or it does more than that > ? > > 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
Re: Subject: Re: [EXTERNAL] Re: how many OSes run on IBMz
For the same reason that Nova (No va) is funny in Hispanic countries; BS has a colloquial meaning in the US. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Arthur Fichtl Sent: Sunday, January 27, 2019 3:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Subject: Re: [EXTERNAL] Re: how many OSes run on IBMz Am 27.01.2019 um 06:00 schrieb IBM-MAIN automatic digest system: > Subject: Re: [EXTERNAL] Re: how many OSes run on IBMz OK, Enlight me, what is BS? Why it's funny? It is Germish and means "Betriebssystem" -- 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: IARV64 - why ABEND rather than return with reason code?
On 1/27/2019 11:55 AM, Charles Mills wrote: One of the side effects of developing in C++ is an end to reliance on dumps as a primary debugging tool. We haven't used dumps as a primary debugging tool in decades. Generally speaking, I'm sure our developers would call z/XDC our primary debugging tool. Our "mantra" for errors that occur in the field is FFDC (First-Failure Data Capture) -- meaning that errors occurring in the field should ideally ALWAYS be solvable without a recreate. If they're not, then we need to improve whatever it is we're capturing. I just can't imagine any trace back or similar information -- no matter how detailed -- that can tell you everything you need to know to solve a storage-related issue. Knowing you ran out of storage is great, but that won't get you anywhere near to understanding the root cause i.e., if there's no space, then why not? What's using it up and why? Is it a looping storage acquisition problem? Or is it really just a failing conditional "freemain" issue? And, if a "freemain" fails, why is that? Wrong start address? Wrong length? Wrong TCB? Wrong key? The same storage being freed twice? Reasons such as EXECUTABLE=YES|NO and others? I would be working with one (or maybe both) hand(s) tied behind my back trying to solve such issues without IPCS SYSTRACE, VSMDATA and RSMDATA. Accept no substitute. ;-) -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol Working Storage size in Dump
I have to do this for all compilers from V3 through V6 Oh the joy of compiler debugging Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Alan Young > Sent: Sunday, January 27, 2019 1:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cobol Working Storage size in Dump > > You did not specify which compiler version or if the dump is from batch or > CICS, but... This link is CICS orientated and was published in 2009, so it > may not apply to the "newer" compilers: > http://www-01.ibm.com/support/docview.wss?uid=swg27017236 . I think the key > in either environment is to find the LE CAA. If the LE CAA is in the dump, > slide 8 has the pointer links to the COBOL TGT and the offset to WS length. > > Alan > > Lizette Koehler wrote: > > Yep, another question > > > > Is there a way in a SVC Dump or SYSUDUMP to determine the size of the > working > > storage section? > > > > My original issue looks to be caused by two things, > > > > 1) The working storage size increased > > 2) There is one 24bit module linked with all the 31bit modules, > thereby > > forcing it below the line > > > > Any guidance appreciated > > > > > > > > Lizette Koehler > > statistics: A precise and logical method for stating a half-truth > inaccurately > > > > -- > 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: Cobol Working Storage size in Dump
You did not specify which compiler version or if the dump is from batch or CICS, but... This link is CICS orientated and was published in 2009, so it may not apply to the "newer" compilers: http://www-01.ibm.com/support/docview.wss?uid=swg27017236 . I think the key in either environment is to find the LE CAA. If the LE CAA is in the dump, slide 8 has the pointer links to the COBOL TGT and the offset to WS length. Alan Lizette Koehler wrote: Yep, another question Is there a way in a SVC Dump or SYSUDUMP to determine the size of the working storage section? My original issue looks to be caused by two things, 1) The working storage size increased 2) There is one 24bit module linked with all the 31bit modules, thereby forcing it below the line Any guidance appreciated Lizette Koehler statistics: A precise and logical method for stating a half-truth inaccurately -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IARV64 - why ABEND rather than return with reason code?
I hear you. I guess we may have to agree to disagree. I think the problem of reporting errors that occurred many layers deep is a general software design problem that has not been adequately solved. The low level component has no idea what the big picture is -- "what am I doing here from the user's point of view?" -- and on the other it is a challenge to pass a variety of different types of errors up the return of a call chain in a way that will lead to error message clarity. Before anyone beats me up for what I am about to say, let me say first that I have been coding assembler since 1968, and it was my primary language for much of the period 1968 to 2008, so please don't accuse me of a lack of assembler knowledge or skills. For the past ten years I have been developing z/OS "system" software primarily in C++. I have become a big believer. I like the productivity -- I think I can write more end-user functionality in a day than an assembler programmer. I like the avoidance of low-level errors -- "oh crap, I forgot that routine needed R2." I like the incredibly optimized object code produced by the compiler. I like the design that emerges from object-oriented thinking. One of the side effects of developing in C++ is an end to reliance on dumps as a primary debugging tool. One, the machine code produced by the C++ compiler is often inscrutable. Two, any dumps tend to be humongous. Three, LE provides pretty good diagnostics and trace-back for ABENDs and similar errors. And four, it is really easy to generate very informative and detail-filled error messages. So I would much rather debug from a specific error message rather than from having to figure out from a dump just which system call failed. In some cases yes, I follow that error message with an ABEND or a throw (which is kind of the C++ equivalent of an ABEND with an ESTAE -- it jumps you from wherever you are to some higher level routine that said "notify me here of any big deal errors below -- kind of like ESTAE). But that is my choice. I wish that MVS would not deny me that choice by "ignoring" COND=YES. To your point about EXECUTABLE=YES, I have always thought that FREEMAIN required too many details. If MVS is to free the storage, what difference does it make if it is executable or not? The address is unique -- why must the subpool be specified? If I were designing FREEMAIN from scratch, I would drop the LENGTH and just always free the entire block. Yes, you would lose the ability to free half of a buffer -- but gain some simplicity of design, and eliminate the nasty bug where you free all but 8 bytes of some repeatedly-obtained area, and never notice it until some customer runs out of (contiguous) memory. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Saturday, January 26, 2019 9:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IARV64 - why ABEND rather than return with reason code? On 1/26/2019 4:37 PM, Charles Mills wrote: > ... You would really rather have your customers and > support staff deal with an S80A and a dump rather than a nice error message > that says "ABC1234E Unable to obtain storage for record work area"? Most conditional storage obtain/release failures occur in routines that are nested very deep. They return up to their caller, who returns to their caller and so forth. By the time you reach a routine that cares enough -- or has the ability -- to write a message, the actual failing scenario has been totally lost in translation. Even if a message is issued by the code requesting the storage service, keep in mind that a "Bad return code from FREEMAIN RC=xx" message tells you absolutely nothing about how to SOLVE the problem. You need to get a dump and issue VERBX VSMDATA/RSMDATA or reproduce under a debugger -- and that isn't always possible. In z/OS V2R4 JES2 is now using EXECUTABLE=NO storage for data areas. Did you know existing FREEMAINs will fail on such storage unless you also code EXECUTABLE=NO? It took quite a while, even with a dump and VSMDATA, to understand why one of our FREEMAINs was abending in that environment. This kind of problem is essentially unsolvable without a dump. Decades of experience won't help you when the rules change out from under you and no dump exists. The reality of what has happened since we removed our conditional storage requests is that we now detect nearly 100% of storage-related errors in-house through our normal testing and incidental usage of our own products before customers ever see them. Previously, messages might have appeared, but they weren't always seen or acted upon. Nothing gets people to take notice better than a dump! Occasionally, we get abends in the field and NOW -- because of the change from conditional to unconditional -- we have excellent FFDC (First-Failure Data Capture). The SDUMP tells everything anyone ever wanted to
Re: IARV64 - why ABEND rather than return with reason code?
Okay. Mea culpa.. COND= is documented at least adequately. (And I was speaking only about IARV64, not GETMAIN or STORAGE, except in my response to @Ed's point.) I think I read only the description of COND=YES: The request is conditional. The request is not abnormally ended for resource unavailability. which certainly does not scream "but will be ABENDed for everything else" and missed the discussion of COND= in general which goes on at some length including In all cases, the request will be abnormally ended for invalid requests. The one valid documentation complaint is that in the Guide, the discussion of COND= is in the wrong place, under the heading about Guard Storage. @Peter, do you want me to put in an RCF, or will you? I suppose the paragraph quoted immediately above might be clearer on what is an invalid request, as opposed to a request that cannot be fulfilled at this time. An IBMer writes me off-list that the IARV64 behavior is identical to conditional GETMAIN in that invalid conditional GETMAIN requests also lead to an ABEND, not a return code. I guess I have not written enough invalid GETMAINs recently to have noticed the distinction. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Sunday, January 27, 2019 5:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IARV64 - why ABEND rather than return with reason code? I too was surprised at "no conditional GETMAINs". No conditional FREEMAINs I can understand. As to "expectations", when you're talking about what can be conveyed with 8 characters (4 for COND, 1 for equal, 3 for YES), or for just about anything else, you really should not "expect" much other than that things will behave as documented. You made an assumption. Was it an unreasonable assumption? No. But it was an assumption nevertheless. And it happened not to be a correct one. There's always room for documentation improvement. As I said, COND=YES means for the most part, return code instead of abend when "no storage available". If that is not clear in the doc, it should be made so. No one would choose document all the specific reasons that could be other than "no storage available". We're talking about the STORAGE macro (since GETMAIN does not have a COND keyword, only a COND indicator, such as the "C" in "RC"). Please re-read the documentation and comment on problems with that documentation, not making assumptions that there is no such documentation about the behavior of COND=YES. 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: Cobol Working Storage size in Dump
Easiest way is probably via the LE data. On Sun, 27 Jan 2019 09:22:26 -0700 Lizette Koehler wrote: :>Yep, another question :> :>Is there a way in a SVC Dump or SYSUDUMP to determine the size of the working :>storage section? :> :>My original issue looks to be caused by two things, :> :> 1) The working storage size increased :> 2) There is one 24bit module linked with all the 31bit modules, thereby :>forcing it below the line :> :>Any guidance appreciated :> :> :> :>Lizette Koehler :>statistics: A precise and logical method for stating a half-truth inaccurately :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cobol Working Storage size in Dump
Each compile unit should tell you how big the working storage area is for those program(s). The link editor to store the compile unit should tell you the attributes, and viewing or listing the individual program members. On Sun, Jan 27, 2019 at 10:22 AM Lizette Koehler wrote: > > Yep, another question > > Is there a way in a SVC Dump or SYSUDUMP to determine the size of the working > storage section? > > My original issue looks to be caused by two things, > > 1) The working storage size increased > 2) There is one 24bit module linked with all the 31bit modules, thereby > forcing it below the line > > Any guidance appreciated > > > > Lizette Koehler > statistics: A precise and logical method for stating a half-truth inaccurately > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Cobol Working Storage size in Dump
Yep, another question Is there a way in a SVC Dump or SYSUDUMP to determine the size of the working storage section? My original issue looks to be caused by two things, 1) The working storage size increased 2) There is one 24bit module linked with all the 31bit modules, thereby forcing it below the line Any guidance appreciated Lizette Koehler statistics: A precise and logical method for stating a half-truth inaccurately -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Subject: Re: [EXTERNAL] Re: how many OSes run on IBMz
On Sun, 27 Jan 2019 11:44:54 +, Sankaranarayanan, Vignesh wrote: > >Seeing a name like BS2000 or BS3000 made me think of a hypothetical marketing >department where their product is so useless, but they proudly sell it, by >naming it BS2000. >They call the new and improved version BS3000. > >It's like how the wall street laughs at the rest of the world when they name >things CDOs, etc. >Sure, CDO has a normal meaning but I'm sure some guy in a suit somewhere knows >its *real* expanded name (inside joke). > Well, the Urban Dictionary entry for CDO links me to "Bear Stearned", clearly more BS. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSAFF and SCHENV
Similar purpose, but different mechanisms. SYSTEM, SYSAFF, and SCHENV all control the system that a job is allowed to run on, but they filter based on different mechanisms. SYSTEM and SYSAFF are based off of the JES2/JES3 member name. SCHENV is based off of your WLM setup; in WLM, you can define scheduling environments, which are essentially arbitrary resources that can be associated with a system image via SDSF or system commands. So with SYSTEM/SYSAFF, you're saying "this job can only run on a system called X." With SCHENV, you're saying that "this job can only run if the system has resources A, B, and C," when A, B, and C are all things that the installation can control whether or not they're defined at any given time. So with scheduling environments, you can have some very basic job scheduling, if you want to. As an example, we typically run our sysplexes with a mix of z/OS release levels (say, V2R1, V2R2, and V2R3). Some of our jobs will only run on a system with release level V2R2 or above. So I can create a scheduling environment called SCHV2R2, and only enable it on systems that are running V2R2 or V2R3. And jobs with SCHENV=SCHV2R2 will be limited to running on those systems. Or you could control it based on the presence of a subsystem, or whether or not the system is DEVTEST, or whatever arbitrary reasons you want to schedule based on. --- Kevin McKenzie External Phone: 845-435-8282, Tie-line: 8-295-8282 z/OS Test Services - Test Architect, Provisioning IBM Mainframe Discussion List wrote on 01/26/2019 10:52:49 PM: > From: Peter > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 01/26/2019 10:53 PM > Subject: SYSAFF and SCHENV > Sent by: IBM Mainframe Discussion List > > Hi > > It is just general question > > I was going through the manual. > > Does SCHENV perform the same function as SYSAFF ? Or it does more than that > ? > > 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
Re: IARV64 - why ABEND rather than return with reason code?
I too was surprised at "no conditional GETMAINs". No conditional FREEMAINs I can understand. As to "expectations", when you're talking about what can be conveyed with 8 characters (4 for COND, 1 for equal, 3 for YES), or for just about anything else, you really should not "expect" much other than that things will behave as documented. You made an assumption. Was it an unreasonable assumption? No. But it was an assumption nevertheless. And it happened not to be a correct one. There's always room for documentation improvement. As I said, COND=YES means for the most part, return code instead of abend when "no storage available". If that is not clear in the doc, it should be made so. No one would choose document all the specific reasons that could be other than "no storage available". We're talking about the STORAGE macro (since GETMAIN does not have a COND keyword, only a COND indicator, such as the "C" in "RC"). Please re-read the documentation and comment on problems with that documentation, not making assumptions that there is no such documentation about the behavior of COND=YES. 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: how many OSes run on IBMz
BS = bull $hit Meaning,.. one is talking meaningless, foolish, s#it. So either BS or horse s#it. Seeing a name like BS2000 or BS3000 made me think of a hypothetical marketing department where their product is so useless, but they proudly sell it, by naming it BS2000. They call the new and improved version BS3000. It's like how the wall street laughs at the rest of the world when they name things CDOs, etc. Sure, CDO has a normal meaning but I'm sure some guy in a suit somewhere knows its *real* expanded name (inside joke). – Vignesh Mainframe Infrastructure Vignesh, that’s not correct. As I worked (in an earlier life) both with BS2000 and BS3000 I could enlight you: Beginning 1966 Siemens/Germany started with manufacturing Computers whose design was developed by RCA (USA). It was named BS1000 and was similar to the IBM/360 (but not identical). When IBM started selling the /370 machines which where equipped with a virtual memory hardware architecture and ran the successor Operating System named OS/VS, Siemens began to produce its own Hardware and developed an OS called BS2000, as well equipped with virtual memory. Regarding the /370 you might want to have a look to this article: https://en.wikipedia.org/wiki/IBM_System/370 BS3000 was marketed by Siemens (its original name was FACOM and the manufacturer was Fujitsu). It had no relations to BS2000. It was sort of Clone of MVS and IBM sued Fujitsu for copyright infringement; there were rumors that IBM demanded (and received) 1 billion US$ from Fujitsu which implied also that the Japanese company was allowed to sell their machines in the domestic market. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Subject: Re: [EXTERNAL] Re: how many OSes run on IBMz
BS = bull $hit Meaning,.. one is talking meaningless, foolish, s#it. So either BS or horse s#it. Seeing a name like BS2000 or BS3000 made me think of a hypothetical marketing department where their product is so useless, but they proudly sell it, by naming it BS2000. They call the new and improved version BS3000. It's like how the wall street laughs at the rest of the world when they name things CDOs, etc. Sure, CDO has a normal meaning but I'm sure some guy in a suit somewhere knows its *real* expanded name (inside joke). – Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List On Behalf Of Arthur Fichtl Sent: 27 January 2019 08:27 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Subject: Re: [EXTERNAL] Re: how many OSes run on IBMz Am 27.01.2019 um 06:00 schrieb IBM-MAIN automatic digest system: > Subject: Re: [EXTERNAL] Re: how many OSes run on IBMz OK, Enlight me, what is BS? Why it's funny? It is Germish and means "Betriebssystem" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Subject: Re: [EXTERNAL] Re: how many OSes run on IBMz
Am 27.01.2019 um 06:00 schrieb IBM-MAIN automatic digest system: Subject: Re: [EXTERNAL] Re: how many OSes run on IBMz OK, Enlight me, what is BS? Why it's funny? It is Germish and means "Betriebssystem" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
