Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS
Perhaps no one has :grokked" the difference is because either there isn't one or because it is so poorly explained and discussed as to be non-existent. This sounds like more marketing hype perpetrated by individuals that know buzzwords and little else. -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Monday, June 20, 2022 6:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS Thanks. I’ve seen something similar on the ACM https://dl.acm.org/doi/pdf/10.1145/1476793.1476796 > On 20 Jun 2022, at 8:51 pm, Joe Monk wrote: > > https://ntrs.nasa.gov/citations/1969381 > > Joe > >> On Mon, Jun 20, 2022 at 7:00 AM David Crayford wrote: >> >> And yet still nobody seems to have grokked the fundamental >> differences between online systems and event-driven architectures. >> This is obviously not the forum for discussions on contemporary >> software architectures. It always deteriorates into a deluge of >> boring and undiscerningposts about how it's nothing new and was >> already done back in the day on a S360 with 4K ram and a paper-taper reader >> held together with gaffer tape. >> >> https://en.wikipedia.org/wiki/Event-driven_architecture >> >>> On 20/06/2022 7:40 pm, Seymour J Metz wrote: >>> Before MQ there were QTAM and TCAM. >> >>> >>> There have been mainframes running real time applications since the >> 1960s. Air traffic control. Airline reservations. Controlling traffic >> lights (UNIVAC, not IBM.) These may not be the best examples, but >> they were the first to come to mind, and used off the shelf mainframes. >>> >>> >>> -- >>> Shmuel (Seymour J.) Metz >>> http://mason.gmu.edu/~smetz3 >>> >>> >>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on >> behalf of René Jansen [rene.vincent.jan...@gmail.com] >>> Sent: Monday, June 20, 2022 5:50 AM >>> To:IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: Modernize Mainframe Applications for Hybrid Cloud with >>> IBM >> and AWS >>> >>> You can make that 'about 30 years ago' - time flies while we’re >>> having >> fun. >>> >>> René. >>> On 20 Jun 2022, at 09:51, Colin Paice wrote: MQ from IBM developed about 20+ years ago helped get from Batch to real time. You put messages to a queue, and it can run IMS transactions (including OTMA), CICS transactions, or even batch!. You can put on >> one member in a sysplex and get in another member. It has single put, and also publish/subscribe capability. Colin >>> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email tolists...@listserv.ua.edu with the message: INFO >>> IBM-MAIN >>> >>> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email tolists...@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 -- 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: Assembler analysis [was: RE: Serverpac installs January 2022 and beyond - Issues]
> ITYM TANSTAAFL, as originally coined by Larry Niven(?) Robert Heinlein, "The Moon is a Harsh Mistress" -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Monday, November 1, 2021 2:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler analysis [was: RE: Serverpac installs January 2022 and beyond - Issues] No, but he did coin "Think of it as evolution in action." From: IBM Mainframe Discussion List on behalf of Allan Staller <0387911dea17-dmarc-requ...@listserv.ua.edu> Sent: Monday, November 1, 2021 4:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler analysis [was: RE: Serverpac installs January 2022 and beyond - Issues] Classification: Confidential ITYM TANSTAAFL, as originally coined by Larry Niven(?) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter x23353 Sent: Monday, November 1, 2021 11:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler analysis [was: RE: Serverpac installs January 2022 and beyond - Issues] [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don't click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] I am aware of only one product (commercial) that claims to be of any help in language conversion for assembler code, but there may be more of which I am unaware. In the one case I am aware of, the results were truly horrible COBOL code that didn't even come close to performing the same function as the assembler from which it was converted. I will not name the product for obvious reasons. In my experience of performing this exact task more than once in my career, I have found that the best route to success is deep reading of the assembler code until you understand the function, input, and output criteria. Once you understand what it is supposed to accomplish, rewriting it manually in a more "modern" language is far more likely to succeed than any mechanical conversion can provide for you. TANSTAFL -- There ain't no such thing as a free lunch. You have to put in the effort to understand the original code or you are probably not going to get it right. If you are lucky there is some kind of programmer-level or at least business-level documentation available describing the original intended function along with its expected inputs and outputs. If not, the only choice left is just reading and understanding the code on your own. Good luck. It can be quite a hard task, but if you put in the effort you can succeed. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Warren Brown Sent: Monday, November 1, 2021 12:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Serverpac installs January 2022 and beyond - Issues Hey experts; I am back with mainframes. I have a new position to analyze to assembly language program. Is their any programs to analyze ASM programs for re-write them to a more modern language. Perhaps their are tools to help me, Thanks, Warren -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -
Re: Programs that work right the first time.
Really? Perhaps you can demonstrate this relationship by providing the appropriate equation or basis for evaluation? I mean, something besides your opinion. Since you claimed it was a reasonable measure, then you need to provide the evidence. BTW, you assumed that the conclusion about adulthood was human only. Please tell how you devised that? Or is it also simply your opinion. It seems that you make a lot of claims absolutely but have no evidence for any of them. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Tuesday, August 24, 2021 6:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Programs that work right the first time. Someone's height is a pretty good measure of where they lie on the scale of adulthood. Except for a small percentage of outliers. On Tuesday, August 24, 2021, 08:48:26 AM EDT, Gerhard Adam wrote: > length isn't a good measure of complexity Really? Who dreams up this nonsense? Define "complexity" and then perhaps an argument can be made about causes or measurements. Until then it is a silly claim. Length is NOT a MEASURE of complexity any more than height is a measure of adulthood. It is foolish to pretend that two characteristics are necessarily the cause or measure of each other. If this is disputed, then give me an equation or a measurement that can be examined to show how the length of code gives rise to increased complexity. Remember the point isn't that complex programs are long, but rather than length is an actual measurement of complexity. However, in the final analysis it comes down to "intent" or "purpose". In short, can an error-free program be produced "on demand"? If the answer is no, then all the claims are nonsense in taking credit for doing something that can't actually be controlled. If the answer is yes, then one can question why the author feels justified in being a thief by not producing such programs all the time. Actually any claim that programs can be produced "error free" and "on demand" is probably nonsense and is justifiably questioned. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Tuesday, August 24, 2021 5:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Programs that work right the first time. I said the vast majority of REXX/CLISTS are not very long. 40 was not MY line in the sand. And that's from 40 years of seeing REXX/CLISTS. Some written in house and some from vendors. On Tuesday, August 24, 2021, 08:00:24 AM EDT, Jeremy Nicoll wrote: On Tue, 24 Aug 2021, at 12:16, Bill Johnson wrote: > The hilarity continues. You say that length isn't a good measure > of complexity I did, that's true. But in what I wrote below I also said that I wasn't claiming that my longest example was particularly complex. Probably the most complex code in what I did describe is in the general macro I wrote (which frontends Kedit's own menu support which is somewhat limited) to handle more complex menus. That's about 650 lines of code. You might be unfamiliar with Kedit; it's a PC version of IBM's Xedit, and it has lots of commands for setting/querying editor status & control parms, plus of course commands that directly edit data. Writing good Kedit macros is broadly comparable to writing Ispf edit macros. > and then search high and low for the longest REXX programs you can > find. That's because of that "40-line script" comment of yours which strongly implied you think that no-one writes larger execs. Incidentally I noticed I have an old copy of an IBM rexx exec here - ISPDTLC - which is 11,174 lines of code. It was written in 1989 so if the same thing still exists I would expect it might have grown a bit. I don't imagine it's trivial. Its purpose is to "Convert SAA Dialog Tag Language tags to ISPF source panels, message files, command tables, etc." Back in the early 1980s I wrote some long (& complex) COBOL programs. I wrote a compiler in COBOL for a document/data definition language I'd invented, then a sort of structured text editor that allowed a user to walk through a document that adhered to such a predefined structure adding, editing & removing text that complied with the definition, moving nodes (chapters, sections, pages ... whatever) around etc. It was, I think, a sort of precursor to a DTD-driven XML editor. It had to handle variable length snippets of text, so part of the editor implemented heap storage for those strings. The total amount of working storage the compiler supported was not enough to hold documents and all the control structures so I wrote a paging subsystem (still in COBOL) to move huge chunks of data in & out of working storage. Quite a lot of the data
Re: Programs that work right the first time.
> length isn't a good measure of complexity Really? Who dreams up this nonsense? Define "complexity" and then perhaps an argument can be made about causes or measurements. Until then it is a silly claim. Length is NOT a MEASURE of complexity any more than height is a measure of adulthood. It is foolish to pretend that two characteristics are necessarily the cause or measure of each other. If this is disputed, then give me an equation or a measurement that can be examined to show how the length of code gives rise to increased complexity. Remember the point isn't that complex programs are long, but rather than length is an actual measurement of complexity. However, in the final analysis it comes down to "intent" or "purpose". In short, can an error-free program be produced "on demand"? If the answer is no, then all the claims are nonsense in taking credit for doing something that can't actually be controlled. If the answer is yes, then one can question why the author feels justified in being a thief by not producing such programs all the time. Actually any claim that programs can be produced "error free" and "on demand" is probably nonsense and is justifiably questioned. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Johnson Sent: Tuesday, August 24, 2021 5:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Programs that work right the first time. I said the vast majority of REXX/CLISTS are not very long. 40 was not MY line in the sand. And that's from 40 years of seeing REXX/CLISTS. Some written in house and some from vendors. On Tuesday, August 24, 2021, 08:00:24 AM EDT, Jeremy Nicoll wrote: On Tue, 24 Aug 2021, at 12:16, Bill Johnson wrote: > The hilarity continues. You say that length isn't a good measure > of complexity I did, that's true. But in what I wrote below I also said that I wasn't claiming that my longest example was particularly complex. Probably the most complex code in what I did describe is in the general macro I wrote (which frontends Kedit's own menu support which is somewhat limited) to handle more complex menus. That's about 650 lines of code. You might be unfamiliar with Kedit; it's a PC version of IBM's Xedit, and it has lots of commands for setting/querying editor status & control parms, plus of course commands that directly edit data. Writing good Kedit macros is broadly comparable to writing Ispf edit macros. > and then search high and low for the longest REXX programs > you can find. That's because of that "40-line script" comment of yours which strongly implied you think that no-one writes larger execs. Incidentally I noticed I have an old copy of an IBM rexx exec here - ISPDTLC - which is 11,174 lines of code. It was written in 1989 so if the same thing still exists I would expect it might have grown a bit. I don't imagine it's trivial. Its purpose is to "Convert SAA Dialog Tag Language tags to ISPF source panels, message files, command tables, etc." Back in the early 1980s I wrote some long (& complex) COBOL programs. I wrote a compiler in COBOL for a document/data definition language I'd invented, then a sort of structured text editor that allowed a user to walk through a document that adhered to such a predefined structure adding, editing & removing text that complied with the definition, moving nodes (chapters, sections, pages ... whatever) around etc. It was, I think, a sort of precursor to a DTD-driven XML editor. It had to handle variable length snippets of text, so part of the editor implemented heap storage for those strings. The total amount of working storage the compiler supported was not enough to hold documents and all the control structures so I wrote a paging subsystem (still in COBOL) to move huge chunks of data in & out of working storage. Quite a lot of the data being moved was itself control tables for other parts of the data. When the thing was in debug mode one could follow the linked-lists that held the whole data-structure together, edit data and pointers & even trigger the program's garbage collector. COBOL was, of course, not the best language for this, but I was required to use an IBM-supported language that our installation had a licence for. It would have been a lot easier to use our Pascal compiler but that came from a German or Austrian university and was ruled out. -- Jeremy Nicoll - my opinions are my own. -- 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
Re: Programs that work right the first time.
It simply seems that most of the comments demonstrate that most posters have no idea what they are doing. (1) Programs are not complex, problems are. If the program is complex and the problem is not, then you don't know what you are doing. (2) Programming is not intended to show how smart or clever an individual is. It should be written to provide the most straightforward solution to others that may need to support it in the future. (3) Most problems are not solved by singular programs, but may involve having multiple modules. If the claim is that this is written in one attempt, without errors, then it is either a lie or dumb luck. (4) If the claim is that programs are written without errors, then the claim is that the programs do not need to be tested. This is clearly a lie. The individual is basing their code on luck and not skill. The question is not whether there were any errors, but whether the author INTRENDED for this code to be error free or whether it was a matter of luck It seems that many of the comments are either taking credit for being lucky or they don't know what they are doing. Often the nation of an error is also discussed in an amateurish fashion. Are we talking about syntax mistakes? Any claim that these don't occur are simply fantasy. Are we talking about logic errors? As mentioned, what does "working right" even mean? It seems that this is a nonsensical discussion. Adam P.S. what kind of foolishness suggests that z/OS is the product of a weekend? Decades of coding, analysis, feedback, and error correction went into it. And yet someone posts this as being concocted by a set of developers are if this were simply discussed over the scribblings on a bar napkin. There is only ONE language and that is the machine language used by the hardware to process directions. Everything else is merely a human translation of that so stop pretending as if this were some great human skill. It is merely a vocation that changes with the next compiler that is made available. One can easily see that after decades of computing, we still don't know how to produce a secure system. We still can't produce code that doesn't crash and we still can't even ensure that we release memory that was acquired by programs. Instead of people being so clever, they might concentrate on producing code that is reliable and actually works in all environments. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bob Bridges Sent: Sunday, August 22, 2021 12:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Programs that work right the first time. Bill, I don't understand what could have pushed your buttons. For instance: BJ> Comparing a 40 line REXX/CLIST “program” to a 10,000 line IMS/COBOL program that scans a parts database is an absolute joke. But the only one making that comparison is you. (Maybe that's why you were the only one laughing :). ) Maybe this is the key: BJ> No bee in my bonnet. Just don’t like braggarts. A few of us (including me) posted "I once wrote a 30-line program that worked right the first time", and what you heard is "am I not amazing, wonderful, brilliant? Do you not all admire me?" Is that what happened? --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* When it comes to cooking, five years ago I felt guilty "just adding water." Now I want to bang the tube against the countertop and have a five-course meal pop out. If it comes with plastic silverware and a plate that self-destructs, all the better. -Erma Bombeck */ --- On 2021-08-21 21:51, Bill Johnson wrote: > “Programming” in REXX, CLIST, and similar types of languages is hardly > programming. Real programming is hundreds or thousands of lines of COBOL, > with IMS, DB2, or CICS calls. I was pretty damn good too. Started off in > COBOL/IMS 4 decades ago. Did a little bit of COBOL/CICS and quite a bit of > COBOL/DB2 later. Try putting together the necessary code to drill down a > hierarchical database like IMS. > > --- On Saturday, August 21, 2021, 9:31 PM, Bob Bridges > wrote: > This part of the thread got me thinking. How often do you write a program > that works right the first time, with no compile or execution errors? I'm > not talking about two-liners, of course, or even ten-liners; let's say 30 or > thereabouts. Please specify the language, too, since it seems to me they > vary in error-prone-ness. > > I've done it occasionally, but by "occasionally" I mean "less than one time > in twenty"; maybe much less, I'm not sure, and only once in my life when > anyone was watching. That was in PL/C; mostly nowadays I write in REXX and > VBA. > > In fact my REXXes typically start out with at least ten or fifteen lines of > boilerplate, and any VBA/Excel program likely relies on a raft of common > functions and/or objects that are part of my regular library, so when I say > "30 lines", some of those lines don't really count.
Re: SMPE
There is only one relevant zone; the TARGET for the system being examined. The GLOBAL zone may have FMIDs deleted depending on the ACCEPT options and items may not even be APPLIED (if they have only been RECEIVEd).The DLIB zone will only show elements that have been ACCEPTed. The PRODUCT function may not be specific enough to indicate all the components that are installed, so the FMID is the only way to be definitive. The LIST command as the way to produce the report and the JCL can be created in using the COMMAND GENERATION component of the SMP/E ISPF function. There are also SMP/E basic utilities to provide a product list based on correlating the FMID and PRODUCT/FEATURE pieces -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, June 17, 2021 11:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMPE Does the OP know what the relevant zones are? Has the installation configured z/OSMF to have the relevant global zones? The mechanics are easy once the requirements are laid out in detail. BTW, should the SMP documentation point to, e.g., z/OSMF, for things that SMP itself doesn't automate, or would that add too much clutter? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Kurt Quackenbush [ku...@us.ibm.com] Sent: Thursday, June 17, 2021 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMPE On 6/16/2021 11:56 AM, CarlosM wrote: > Would anyone have the JCL/statements necessary to produce a SMPE > report of ALL installed products? To be sure we're using the same terminology, a "PRODUCT" to SMP/E is a collection of FEATUREs, and each FEATURE is a collection of FMIDs. A PRODUCT is identified by its Product ID and VRM. For example, z/OS V2.4 has product ID "5650-ZOS" and VRM "2.4.0", which has a bunch of FEATUREs, like the z/OS Base, and that FEATURE has lots of FMIDs, like HBB77C0. Is that the kind of "product" information you're looking for? Its easy to get a list of FMIDs which are installed in a particular target zone. Like this: //SMPE EXEC PGM=GIMSMP //SMPCSI DD DISP=SHR,DSN=globalZoneCsiName //SMPOUT DD SYSOUT=* //SMPLIST DD SYSOUT=* //SMPCNTL DD * SET BDY(targetZoneName). LIST FUNCTIONS. /* There is no simple SMP/E LIST command to precisely display the installed PRODUCTs. You can list the PRODUCTs which have been received, like this, but not which have been installed into a particular target zone. //SMPE EXEC PGM=GIMSMP //SMPCSI DD DISP=SHR,DSN=globalZoneCsiName //SMPOUT DD SYSOUT=* //SMPLIST DD SYSOUT=* //SMPCNTL DD * SET BDY(GLOBAL). LIST PRODUCT FEATURE. /* A better approach is to use z/OSMF Software Management. The Products page displays exactly which Products, Features, and FMIDs are installed. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- 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
Re: How to compare parameters in one z/Os with parameters in another z/OS
This is impossible. The decision must be made in advance to determine what a particular value should be or how it should be interpreted. There is no software (or healthchecker) that can take the place of actually looking at a value and assessing its use/value There are no silver bullets It actually has to be known what has been specified, why it was specified and how comparable it is to other definitions. This notion that systems can be set up in ignorance cannot occur and suddenly have the knowledge be magically available. If this could be done by software then one doesn't need systems programmers Adam -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Sunday, June 13, 2021 9:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to compare parameters in one z/Os with parameters in another z/OS Isn't this pretty much what NewEra's IMAGE Focus does? You need "PARMLIB intelligence." You can't just do a character compare. For example you have to understand which PARMLIB statements are statement order independent, and which are not. I think that is what IMAGE Focus does. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Sunday, June 13, 2021 6:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to compare parameters in one z/Os with parameters in another z/OS There is no getting around the manual examination that is required. Once this is completed then you can evaluate whether parameters should be shared, copied, etc. to establish how they are to managed into the future. There is no other way, since it seems that no one knows that has actually been specified/. -- 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: How to compare parameters in one z/Os with parameters in another z/OS
There is no getting around the manual examination that is required. Once this is completed then you can evaluate whether parameters should be shared, copied, etc. to establish how they are to managed into the future. There is no other way, since it seems that no one knows that has actually been specified/. Adam -Original Message- From: IBM Mainframe Discussion List On Behalf Of ibmmain Sent: Sunday, June 13, 2021 6:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to compare parameters in one z/Os with parameters in another z/OS Dear We could write a program to handle specific parameters and values before comparing them against the target library We found that some parameters are just defined in a different order in different z/os, but they are actually the same definition Some parameter definitions have different starting columns, and they also are the same definition We don't know how to handle this situation. Do we need to make sure they are in the same order? Thanks a lot! Jason Cai -- Original -- From: "IBM Mainframe Discussion List"
Re: How to compare parameters in one z/Os with parameters in another z/OS
There is a utility program (IEBCOMPR) and functions like SuperCompare to do this. It is quite trivial. Unless you mean that these libraries are not truly comparable in which case no comparison is possible. Under those conditions you would have to have a program which could have specific parameters and values identified and then compared against the target library. To the best of my knowledge, that is certainly not freely available. Adam P.S. I am assuming that the notion of symbols has been properly pursued and evaluated. -Original Message- From: IBM Mainframe Discussion List On Behalf Of ibmmain Sent: Sunday, June 13, 2021 4:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to compare parameters in one z/Os with parameters in another z/OS Hi all We want to make sure two z/OS use the same parameters(PARMLIB,VTAMLST,and so on) Because there is some parameter which is multiline in member, it isn't easy to compare them. Is there any way to compare parameters in one z/Os with parameters in another z/OS Any thoughts/comments/suggestions would be greatly appreciated Best Regards, Jason Cai -- 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: DFSMS Move Dataset
DFSMSdss will do and it can also be invoked from ISMF where a filter list can be build for the files to be moved Get Outlook for iOS On Fri, May 15, 2020 at 10:41 AM -0700, "esst...@juno.com" wrote: Hello. Does IBM (DFSMS) have a utility that will move VSAM and/or non-VSAM dataset to a different VOLUME ? . Paul D'Angelo * * * -- 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
Really? There’s lots that it could do? So why not just read the DSCB for how much is free and do the calculation that has been on every 3390 Reference card for 30 years This is done all the time and in a variety of ways. This problem was readily assessed for decades using a subroutine. This has always been something that could readily be done until people start putting language restrictions on it. It isn’t that the info isn’t available, it is simply that the information isn’t available given the restrictions placed on the problem Get Outlook for iOS On Thu, May 14, 2020 at 1:56 PM -0700, "Charles Mills" wrote: There is lots it could do! Make a decision on "strategy" based on the volume of input, for example. Do I process it all or cut off after 'n' records and do more on the next run? Do I read the file into an in-memory table and access records there, or do I load it into a VSAM file for direct access? Do I invoke an external sort or use an internal sort? Or a thousand other things. It is wrong as @Shmuel points out to preclude questioning the necessity of doing something exactly as the OP suggests. It is equally wrong to assume there could be no good reason for doing it the OP's way. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard adam Sent: Thursday, May 14, 2020 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? It is easy to say that a COBOL program needs to “know” this but it is nonsense since there is nothing a COBOL program can do with this info. If it turns out to really be necessary then a subroutine can be written (as it has been done for decades) to provide this information. If the question is simply to bitch about why z/OS does do this automatically via a call or something then the complaint is directed to the wrong group -- 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: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
It is easy to say that a COBOL program needs to “know” this but it is nonsense since there is nothing a COBOL program can do with this info. If it turns out to really be necessary then a subroutine can be written (as it has been done for decades) to provide this information. If the question is simply to bitch about why z/OS does do this automatically via a call or something then the complaint is directed to the wrong group Get Outlook for iOS On Thu, May 14, 2020 at 11:43 AM -0700, "Seymour J Metz" wrote: Because the information that he's asking for isn't in the catalog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joe Monk [joemon...@gmail.com] Sent: Thursday, May 14, 2020 2:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? I dont see why you cant just call IDCAMS in batch (regardless of the language used) and get the file size from the catalog? Joe On Thu, May 14, 2020 at 1:16 PM Seymour J Metz wrote: > That wasn't what he wrote, but I agree that it could have been phrased > better. Still, the question is relevant; if we (TINW) knew why the OP was > asking and what was behind his question, we would be better positioned to > address the underlying problem. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Charles Mills [charl...@mcn.org] > Sent: Thursday, May 14, 2020 1:46 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > I hear you @Shmuel and agree, but "why does it have to be solved in COBOL?" > Well gee, I would guess because the application that needs to know is > already written -- and it's written in COBOL. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Seymour J Metz > Sent: Thursday, May 14, 2020 10:29 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > It is very common for someone with a problem to assume that it has to be > fixed in a certain way, and to ask about that way rather than the actual > problem. Asking for clarification never hurts, and often helps. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of > Charles Mills [charl...@mcn.org] > Sent: Thursday, May 14, 2020 1:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > Of course it does not matter to COBOL! > > But it might matter to one or more applications that might just happen to > be > written in COBOL! > > No disrespect @Gil but this kind of answer drives me crazy. One thinks > about > a problem. It is a big and complex problem with multiple unknowns and > tradeoffs. There are many ways one might at least partially solve it. One > thinks at length about all the tradeoffs. One finally drills down on one > particular approach ... but wait! There is one detail necessary for the > solution to work that one does not know. > > So one posts on IBMMAIN "how can a COBOL program running as a started task > but not APF-authorized determine how many widgets are in a bushel?" > > And someone immediately replies "why would you want to do that?" > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Thursday, May 14, 2020 9:57 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, > non-zFS, non-database files? > > On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote: > > >Thanks Lizette, I had forgotten about LISTDSI. The context here was a > need > for an API callable from a batch COBOL program, but that could be done too, > if somewhat clumsily due to the requirement for LISTDSI to be executed in a > TSO environment. > > > >I sent my co-worker on a search at cbttape.org for something he could > use. > > > Why? Where does this matter to COBOL? > > The VTOC-based approaches give at least an upper bound, which might > suffice for capacity calculations. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
Rightfully people would like to know what the purpose is. It isn’t simply a question of acquiring the info, but also what you intend to do about it afterwards. Since the question pertains to COBOL I’m guessing they haven’t thought that far ahead Get Outlook for iOS On Thu, May 14, 2020 at 11:16 AM -0700, "Seymour J Metz" wrote: That wasn't what he wrote, but I agree that it could have been phrased better. Still, the question is relevant; if we (TINW) knew why the OP was asking and what was behind his question, we would be better positioned to address the underlying problem. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 14, 2020 1:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? I hear you @Shmuel and agree, but "why does it have to be solved in COBOL?" Well gee, I would guess because the application that needs to know is already written -- and it's written in COBOL. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, May 14, 2020 10:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? It is very common for someone with a problem to assume that it has to be fixed in a certain way, and to ask about that way rather than the actual problem. Asking for clarification never hurts, and often helps. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Thursday, May 14, 2020 1:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? Of course it does not matter to COBOL! But it might matter to one or more applications that might just happen to be written in COBOL! No disrespect @Gil but this kind of answer drives me crazy. One thinks about a problem. It is a big and complex problem with multiple unknowns and tradeoffs. There are many ways one might at least partially solve it. One thinks at length about all the tradeoffs. One finally drills down on one particular approach ... but wait! There is one detail necessary for the solution to work that one does not know. So one posts on IBMMAIN "how can a COBOL program running as a started task but not APF-authorized determine how many widgets are in a bushel?" And someone immediately replies "why would you want to do that?" Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, May 14, 2020 9:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files? On Thu, 14 May 2020 16:31:45 +, Farley, Peter x23353 wrote: >Thanks Lizette, I had forgotten about LISTDSI. The context here was a need for an API callable from a batch COBOL program, but that could be done too, if somewhat clumsily due to the requirement for LISTDSI to be executed in a TSO environment. > >I sent my co-worker on a search at cbttape.org for something he could use. > Why? Where does this matter to COBOL? The VTOC-based approaches give at least an upper bound, which might suffice for capacity calculations. -- gil -- 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 -- 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
Re: z/OS performance question
Delays don’t really count for anything unless we know that these jobs are missing their objectives and by how much. Delays always occur. If the jobs are meeting their objectives then there is no performance problem (as far as the system is concerned). The problem, then, is that the WLM definitions are incorrect Get Outlook for iOS On Fri, May 1, 2020 at 10:29 AM -0700, "Edgington, Jerry" wrote: To anyone, I am not a performance person at all, but can someone help me with pointing me in the right direction. We are running a small SYSplex, but we are getting delays on one LPAR, PROC-XCFAS *SYSTEMPROC-XCFAS 3.7 users ALL STCPROC-XCFAS 3.2 users IMS PROC-XCFAS 26.0 % delay RMFPROC-XCFAS 18.0 % delay RMFGAT PROC-XCFAS 21.0 % delay IMSCTL PROC-XCFAS 25.0 % delay TN3270 PROC-XCFAS 28.0 % delay VTAM PROC-XCFAS 19.0 % delay Also, we are ACF2 shop and our production CICS regions are getting delays: ENQ -ACFVSAM 38.0 % delay LOGONIDS ENQ -ACF2ACB 100.0 % delay LOGONIDS So any help would be great. Thanks, Jerry Edgington -- 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: [External] Re: Here we go again;
So you agree that poor Blocksizes give rise to poor disk usage? As to space allocations, I’m sorry but for as many problems as you’re describing the staff couldn’t have been that serious. If management was as serious as being claimed there would have been no problem. Yet I find that few people understand blocking. They invariably get it wrong with load modules, VSAM, ISAM (in the old days) and BDAM. Come to think of it, this only applies to sequential files. As for incompetent programmers? Spare me the exaggerations. Even today, few people understand it and most get it wrong when assuming that half-track blocking is optimum when other than sequential files are considered Get Outlook for iOS On Wed, Apr 22, 2020 at 4:11 PM -0700, "Gibney, Dave" wrote: Full volumes due to excessive space wasted due to crap blksizes had everything to do with x37 abends. I am sorry that your experience included so many incompetent programmers. Mine did care, and my management cared more. Before SDB, it was a periodic take for me to review and clean DASD, fix BLKSIZES, Etc. In that era, I was cheaper the STOPX37. I'm not cheaper today. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gerhard adam > Sent: Wednesday, April 22, 2020 3:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Re: Here we go again; > > > > > > X37 abends have nothing to do with block sizes Furthermore the role > of secondary space allocations was so bad among programmers that many > installations installed a vendor product called STOPX37 because it was easier > then actual planning and calculating space. > > > > Get Outlook for iOS > > > > > > > On Wed, Apr 22, 2020 at 3:35 PM -0700, "Seymour J Metz" > wrote: > > > > > > > > > > > Kilobytes? Not unless you started on a 305 or 650. Even on the 650 it was > 6,000,000 digits. The disks on the 1401 and 7000 series were somewhat larger, > even before the 1301, and the 2311 larger still. Only the 1130 was close to > the > 650's mere megabyte. > > > -- > Shmuel (Seymour J.) Metz > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!JmPEg > BY0HMszNaDT!5_-I8aqsL8R5a9A- > Z5U0vXKBJCfgDQPHsOlqGSGWCHFohipMYPShrUZqJpXBag$ > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Pommier, Rex [rpomm...@sfgmembers.com] > Sent: Wednesday, April 22, 2020 3:07 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Re: Here we go again; > > Agreed. Another thing to remember was that we were dealing with disk > volumes measured in kilobytes or megabytes instead of terabytes. In > addition, the site I cut my teeth on had all removable disk packs that got > rotated onto the drives for processing of each application. Every byte saved > per record gave us the better chance of fitting the entire set of datasets on > a > single disk set so we could process it. > > Rex > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Charles Mills > Sent: Wednesday, April 22, 2020 12:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [External] Re: Here we go again; > > Faulty logic there. A byte here and byte there and pretty soon you have to > buy ANOTHER unit of DASD. It costs the same empty or full, but if it gets > nearly full you have to pay for another. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gerhard adam > Sent: Wednesday, April 22, 2020 10:06 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Here we go again; > > > > > > The notion of “savings” was marketing nonsense. The DASD was paid for > regardless of whether it held a production database or someone’s golf > handicap. > It cost the same whether it was empty or full. The notion of “saving” was > nonsense and even under the best of circumstances could only be deferred > expenses > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not > the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that an
Re: [External] Re: Here we go again;
X37 abends have nothing to do with block sizes Furthermore the role of secondary space allocations was so bad among programmers that many installations installed a vendor product called STOPX37 because it was easier then actual planning and calculating space. Get Outlook for iOS On Wed, Apr 22, 2020 at 3:35 PM -0700, "Seymour J Metz" wrote: Kilobytes? Not unless you started on a 305 or 650. Even on the 650 it was 6,000,000 digits. The disks on the 1401 and 7000 series were somewhat larger, even before the 1301, and the 2311 larger still. Only the 1130 was close to the 650's mere megabyte. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Pommier, Rex [rpomm...@sfgmembers.com] Sent: Wednesday, April 22, 2020 3:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: Here we go again; Agreed. Another thing to remember was that we were dealing with disk volumes measured in kilobytes or megabytes instead of terabytes. In addition, the site I cut my teeth on had all removable disk packs that got rotated onto the drives for processing of each application. Every byte saved per record gave us the better chance of fitting the entire set of datasets on a single disk set so we could process it. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Wednesday, April 22, 2020 12:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Here we go again; Faulty logic there. A byte here and byte there and pretty soon you have to buy ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly full you have to pay for another. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard adam Sent: Wednesday, April 22, 2020 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Here we go again; The notion of “savings” was marketing nonsense. The DASD was paid for regardless of whether it held a production database or someone’s golf handicap. It cost the same whether it was empty or full. The notion of “saving” was nonsense and even under the best of circumstances could only be deferred expenses -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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
Re: Here we go again;
There also seems to be a lapse in memory regarding the reference cards provided by IBM for the various model DASD is where one could look up the record size and view the table for the recommended Blocksize. In addition these cards also provided the detailed calculations/equations to determine these values without looking them up Get Outlook for iOS On Wed, Apr 22, 2020 at 1:00 PM -0700, "scott Ford" wrote: David, I laugh at these comments/observations. Early days 70-80s System Programmers like myself helped programmers determine blocksize and dataset location, etc. and then DBAs were born or made and then the system optimized. Evolution Scott On Wed, Apr 22, 2020 at 3:44 PM Seymour J Metz wrote: > My first computer had a 2,000 word drum, a 60 word core memory, a 600,000 > word disk drive and two tape drives. I may have been a tad more constrained > than you were when you started. I agree with Mr. Adam; people would have > saved far more DASD space with intelligent choice of block size than the > miniscule amount they saved by truncating the year. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Joel C. Ewing [jcew...@acm.org] > Sent: Wednesday, April 22, 2020 3:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Here we go again; > > Should we presume you didn't work on mainframes prior to the advent of > cheap memory and cheap RAID DASD in TB chunks? > > Even after advent of 3380, 3390, and even native 3390-3, drives our > company didn't lease DASD drives without doing cost analysis. In late > 1970's and early 1980's we were on 3330's and later 3350's, where > physical constraints were also an issue -- when I started as SysProg in > 1978, the computer room was maxed out space-wise at 29 3330 drives, or > only 2.9GB total DASD space. We didn't have DASD sitting around that > wasn't 95% or more utilized. Batch jobs typically got one dedicated > 3330 DASD work volume that they could allocate only for the duration of > the job stream, staging data from/to tape as necessary to fit and to > preserve for next job-stream run. It wasn't until 1995 and beyond, > that it finally made economic sense for us to acquire DASD capacity a > year or two before we might actually be able to justify a need. > > Our company believed in investing more money in people to retain good IT > personnel rather than throwing money at hardware. That mind-set was one > of the reasons why of the 50 some-odd companies in that line of > business in 1950, of the 3 still in business in 2000, one was ours. > > Saving one or two bytes per date field in that kind of environment was > not "marketing nonsense". By performance tuning and efficient > application design we consistently delayed the need for a DASD or > processor upgrades, resulting in *considerable* monetary savings over > decades. You don't "waste" DASD or memory space just because it's > available at the time without first considering the long-term impact on > future upgrades. A "good" programmer/analyst was trained to err on the > side of conserving resources. > > You can't judge decisions of the past without first understanding the > cost, physical space, memory, and I/O configuration constraints under > which those decisions were made. Unlike now where where easy > incremental upgrades are possible, back then every upgrade, assuming one > was possible, involved a substantial cost increase. > JC Ewing > > On 4/22/20 12:05 PM, Gerhard adam wrote: > > > > > > > > > > The notion of “savings” was marketing nonsense. The DASD was paid > for regardless of whether it held a production database or someone’s golf > handicap. > > It cost the same whether it was empty or full. The notion of “saving” > was nonsense and even under the best of circumstances could only be > deferred expenses > > > > > > > > Get Outlook for iOS > > > > > > > > > > > > > > On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" < > dspiegel...@hotmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > It was also the physical size of the dataset. > > > > On 2020-04-22 12:55, Gibney, Dave wrote: > >> In the 80's a byte of DASD savings could be thousands of dollars. > >> > >>> -Original Message- > >>> From: IBM Mainfram
Re: [External] Re: Here we go again;
Why did you have to go to the programmers to make sure they were using proper block sizes if this were common practice? Get Outlook for iOS On Wed, Apr 22, 2020 at 12:34 PM -0700, "Pommier, Rex" wrote: Sorry, we'll have to agree to disagree. It wasn't mythology at my places of business. When I was in application development, disk and other resource efficiency was of paramount concern and when I moved into systems programming I got to be the one going to the developers and making sure they didn't use bad blocking. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gerhard adam Sent: Wednesday, April 22, 2020 2:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: Here we go again; ... and so goes the mythology. The truth is that programmers routinely used lousy block sizes and wastes tremendous amounts of space. JCL sizes were rarely scrutinized nor was data set usage. It was entirely possible for test data to exist for weeks or months beyond its usefulness This isn’t to say that money was obviousness spent and even wasted, but few installations took managing their DASD seriously. They would worry about saving a byte by packing a date while wasting 100 tracks due to poor blocking. This is why nothing really happened until System Determined Blocksize, and the Storage Administrator tools became available. People certainly wrung their hands but rarely did anything about it Get Outlook for iOS On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex" wrote: Agreed. Another thing to remember was that we were dealing with disk volumes measured in kilobytes or megabytes instead of terabytes. In addition, the site I cut my teeth on had all removable disk packs that got rotated onto the drives for processing of each application. Every byte saved per record gave us the better chance of fitting the entire set of datasets on a single disk set so we could process it. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Wednesday, April 22, 2020 12:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Here we go again; Faulty logic there. A byte here and byte there and pretty soon you have to buy ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly full you have to pay for another. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard adam Sent: Wednesday, April 22, 2020 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Here we go again; The notion of “savings” was marketing nonsense. The DASD was paid for regardless of whether it held a production database or someone’s golf handicap. It cost the same whether it was empty or full. The notion of “saving” was nonsense and even under the best of circumstances could only be deferred expenses -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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 The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether
Re: [External] Re: Here we go again;
Sorry, but “several models of 3380”? If 3380k held almost 2GB per module and you saved one byte per record, then you saved the one byte over 2 billion records to save just one 3380K’s worth of data. Forgive me for being skeptical Get Outlook for iOS On Wed, Apr 22, 2020 at 12:34 PM -0700, "Pommier, Rex" wrote: Sorry, we'll have to agree to disagree. It wasn't mythology at my places of business. When I was in application development, disk and other resource efficiency was of paramount concern and when I moved into systems programming I got to be the one going to the developers and making sure they didn't use bad blocking. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gerhard adam Sent: Wednesday, April 22, 2020 2:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: Here we go again; ... and so goes the mythology. The truth is that programmers routinely used lousy block sizes and wastes tremendous amounts of space. JCL sizes were rarely scrutinized nor was data set usage. It was entirely possible for test data to exist for weeks or months beyond its usefulness This isn’t to say that money was obviousness spent and even wasted, but few installations took managing their DASD seriously. They would worry about saving a byte by packing a date while wasting 100 tracks due to poor blocking. This is why nothing really happened until System Determined Blocksize, and the Storage Administrator tools became available. People certainly wrung their hands but rarely did anything about it Get Outlook for iOS On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex" wrote: Agreed. Another thing to remember was that we were dealing with disk volumes measured in kilobytes or megabytes instead of terabytes. In addition, the site I cut my teeth on had all removable disk packs that got rotated onto the drives for processing of each application. Every byte saved per record gave us the better chance of fitting the entire set of datasets on a single disk set so we could process it. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Wednesday, April 22, 2020 12:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Here we go again; Faulty logic there. A byte here and byte there and pretty soon you have to buy ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly full you have to pay for another. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard adam Sent: Wednesday, April 22, 2020 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Here we go again; The notion of “savings” was marketing nonsense. The DASD was paid for regardless of whether it held a production database or someone’s golf handicap. It cost the same whether it was empty or full. The notion of “saving” was nonsense and even under the best of circumstances could only be deferred expenses -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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 The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in err
Re: Here we go again;
The truth is that everyone has such fond memories of their efforts yet most were surprised when System Determined Blocksize was actually introduced. They have forgotten the TSO CLISTS that were often written so that programmers would specify more efficient block sizes. Even today, the average IT person has a poor understanding of blocking and gets confused when load libraries are involved (don’t understand RECFM=U) Get Outlook for iOS On Wed, Apr 22, 2020 at 12:15 PM -0700, "Joel C. Ewing" wrote: Should we presume you didn't work on mainframes prior to the advent of cheap memory and cheap RAID DASD in TB chunks? Even after advent of 3380, 3390, and even native 3390-3, drives our company didn't lease DASD drives without doing cost analysis. In late 1970's and early 1980's we were on 3330's and later 3350's, where physical constraints were also an issue -- when I started as SysProg in 1978, the computer room was maxed out space-wise at 29 3330 drives, or only 2.9GB total DASD space. We didn't have DASD sitting around that wasn't 95% or more utilized. Batch jobs typically got one dedicated 3330 DASD work volume that they could allocate only for the duration of the job stream, staging data from/to tape as necessary to fit and to preserve for next job-stream run. It wasn't until 1995 and beyond, that it finally made economic sense for us to acquire DASD capacity a year or two before we might actually be able to justify a need. Our company believed in investing more money in people to retain good IT personnel rather than throwing money at hardware. That mind-set was one of the reasons why of the 50 some-odd companies in that line of business in 1950, of the 3 still in business in 2000, one was ours. Saving one or two bytes per date field in that kind of environment was not "marketing nonsense". By performance tuning and efficient application design we consistently delayed the need for a DASD or processor upgrades, resulting in *considerable* monetary savings over decades. You don't "waste" DASD or memory space just because it's available at the time without first considering the long-term impact on future upgrades. A "good" programmer/analyst was trained to err on the side of conserving resources. You can't judge decisions of the past without first understanding the cost, physical space, memory, and I/O configuration constraints under which those decisions were made. Unlike now where where easy incremental upgrades are possible, back then every upgrade, assuming one was possible, involved a substantial cost increase. JC Ewing On 4/22/20 12:05 PM, Gerhard adam wrote: > > > > > The notion of “savings” was marketing nonsense. The DASD was paid for > regardless of whether it held a production database or someone’s golf > handicap. > It cost the same whether it was empty or full. The notion of “saving” was > nonsense and even under the best of circumstances could only be deferred > expenses > > > > Get Outlook for iOS > > > > > > > On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" wrote: > > > > > > > > > > > It was also the physical size of the dataset. > > On 2020-04-22 12:55, Gibney, Dave wrote: >> In the 80's a byte of DASD savings could be thousands of dollars. >> >>> -Original Message- >>> From: IBM Mainframe Discussion List On >>> Behalf Of Phil Smith III >>> Sent: Wednesday, April 22, 2020 9:12 AM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: Here we go again; >>> >>> As others have suggested, many companies do still have SSNs stored as >>> packed decimal. So sure, a namespace expansion is possible, but it's a >>> bigger >>> change than one might think, however it's done. I've even seen at least one >>> company who stored them as binary! I sure hope someone got a big bonus >>> for saving that byte... >>> >>> >>> >>> >>> >>> Peter Farley wrote: >>> >>>> There are also many non-human entities like corporations that use the >>> same SSN value space. >>> >>> >>> >>>> There are a LOT of those . . . and they spring up and fade away at a rate >>>> far >>> higher than human births and deaths. >>> >>> >>> >>> They use the same namespace--that is, if your SSN is 123-45-6789, an estate >>> or business could also have that number. Since they're uses
Re: [External] Re: Here we go again;
... and so goes the mythology. The truth is that programmers routinely used lousy block sizes and wastes tremendous amounts of space. JCL sizes were rarely scrutinized nor was data set usage. It was entirely possible for test data to exist for weeks or months beyond its usefulness This isn’t to say that money was obviousness spent and even wasted, but few installations took managing their DASD seriously. They would worry about saving a byte by packing a date while wasting 100 tracks due to poor blocking. This is why nothing really happened until System Determined Blocksize, and the Storage Administrator tools became available. People certainly wrung their hands but rarely did anything about it Get Outlook for iOS On Wed, Apr 22, 2020 at 12:08 PM -0700, "Pommier, Rex" wrote: Agreed. Another thing to remember was that we were dealing with disk volumes measured in kilobytes or megabytes instead of terabytes. In addition, the site I cut my teeth on had all removable disk packs that got rotated onto the drives for processing of each application. Every byte saved per record gave us the better chance of fitting the entire set of datasets on a single disk set so we could process it. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Wednesday, April 22, 2020 12:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Here we go again; Faulty logic there. A byte here and byte there and pretty soon you have to buy ANOTHER unit of DASD. It costs the same empty or full, but if it gets nearly full you have to pay for another. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard adam Sent: Wednesday, April 22, 2020 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Here we go again; The notion of “savings” was marketing nonsense. The DASD was paid for regardless of whether it held a production database or someone’s golf handicap. It cost the same whether it was empty or full. The notion of “saving” was nonsense and even under the best of circumstances could only be deferred expenses -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- 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: Here we go again;
The notion of “savings” was marketing nonsense. The DASD was paid for regardless of whether it held a production database or someone’s golf handicap. It cost the same whether it was empty or full. The notion of “saving” was nonsense and even under the best of circumstances could only be deferred expenses Get Outlook for iOS On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" wrote: It was also the physical size of the dataset. On 2020-04-22 12:55, Gibney, Dave wrote: > In the 80's a byte of DASD savings could be thousands of dollars. > >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Phil Smith III >> Sent: Wednesday, April 22, 2020 9:12 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Here we go again; >> >> As others have suggested, many companies do still have SSNs stored as >> packed decimal. So sure, a namespace expansion is possible, but it's a bigger >> change than one might think, however it's done. I've even seen at least one >> company who stored them as binary! I sure hope someone got a big bonus >> for saving that byte... >> >> >> >> >> >> Peter Farley wrote: >> >>> There are also many non-human entities like corporations that use the >> same SSN value space. >> >> >> >>> There are a LOT of those . . . and they spring up and fade away at a rate >>> far >> higher than human births and deaths. >> >> >> >> They use the same namespace--that is, if your SSN is 123-45-6789, an estate >> or business could also have that number. Since they're uses for different >> things, it's more that they happened (!) to choose the same format than that >> they're "the same". (And actually they're theoretically formatted >> differently: >> an EIN is xx-xxx vs. the SSN xxx-xx-, not that most folks store them >> with the hyphens.) >> >> >> >> ...phsiii >> >> >> -- >> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New Jersey Pleas for COBOL Coders for Mainframes Amid Coronavirus Pandemic
COBOL is not taught because those that know it can make a much better living using it than teaching college classes to people that believe it is “dead” Of course the latter opinion is stupid on the face of it. After all, how does one replace systems that are not understood? From scratch? LOL Get Outlook for iOS On Sun, Apr 5, 2020 at 1:07 PM -0700, "Steve Thompson" wrote: I have asked and been told that various universities do not teach languages, they teach theory. So the students learn an object oriented language such as C++ or Java online(?). The statements made and questions asked of/by contract programmers (off shore) relative to COBOL — I believe it. Sent from my iPhone — small keyboarf, fat fungrs, stupd spell manglr. Expct mistaks > On Apr 5, 2020, at 3:09 PM, Bob Bridges wrote: > > Says here "COBOL is a dead language that hasn't been taught in most > universities for decades, and the rare COBOL coders command anywhere from > $55 to $85 an hour". > > I'm reminded that five or ten years ago one of my sons heard my standard > rant #37 about mainframes, and thought maybe he should learn to work with > them (thinking it might lead to job security, in which I imagine he was not > entirely wrong). For a few weeks I called around trying to find out what it > would cost me to rent space for two accounts on an IBM mainframe somewhere. > My questions must have been repeated here and there, for eventually an IBM > guy called me and said if I could get the local university to teach a few > courses on mainframes, they'd have to rent space on a mainframe for the > students and IBM would ~give~ me two accounts so I could teach my son. I > did call one of the local universities, one I'd worked at for two years, but > couldn't drum up any interest. > > The IBM guy also said that companies were getting so desperate for mainframe > trainees that they were sponsoring college courses their own selves, just so > they'd have someone they could hire later. > > COBOL is by no means a "dead language", in any practical sense, but > apparently the writer got it right that it isn't being taught in schools. > > Dunno about 55 to 85 $/hr, though, unless things have gotten a lot worse > since I got into the security side. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* D'you call life a bad job? Never! We've had our ups and downs, we've > had our struggles, we've always been poor, but it's been worth it, ay, worth > it a hundred times I say when I look 'round at my children. -from _Of Human > Bondage_ by W Somerset Maugham */ > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Phil Smith III > Sent: Sunday, April 5, 2020 10:23 > > https://www.tomshardware.com/news/new-jersey-cobol-coders-mainframes-coronav -- 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: Wanted Civil programmers in New Jersey urgently
Most of it is BS. Scratch the surface and you usually find capacity or performance issues around the Windows servers while the management blithely blames the mainframe because they don’t know how anything works. Get Outlook for iOS On Sun, Apr 5, 2020 at 12:15 PM -0700, "Martin Packer" wrote: I came to the opposite conclusion: I couldn't see why coding was required unless new function was DESPERATELY needed. The word in bold because that seems very risky - going around changing function at a time like this. And, because my lens is more-or-less performance, I thought making the application scale was the urgent and safer thing. Yes, I realise application changes can be necessary to make something scale but then we're back to desperation. :-( Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Laurence Chiu To: IBM-MAIN@LISTSERV.UA.EDU Date: 05/04/2020 20:06 Subject:[EXTERNAL] Wanted Civil programmers in New Jersey urgently Sent by:IBM Mainframe Discussion List it seems that the huge increase in benefit request in New Jersey is causing their benefit systems to be overloaded and not able to handle the volume of requests. It doesn't seem like a load issue but more the application needs to be changed. Otherwise you would just throw more MIPS at it https://urldefense.proofpoint.com/v2/url?u=https-3A__www.theregister.co.uk_2020_04_05_new-5Fjersey-5Fseeks-5Fcobol-5Fvolunteers_&d=DwIBaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ&m=we9iQYSSOE8VzuyXv27f9iKmNJlYkPMnUAf4sG-UjZA&s=UgOg-N0E7RFnAw49opRaW9-gaTi6S8WvCM4bi73z9FM&e= -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: What is a mainframe?
I think you are absolutely correct There is a reason why VTAM adopted APPN, because it was impossible for VTAM to look and behave as if it were the entire center for every communications need. TCP/IP was inevitable given its large penetration into the home consumer market and the cost for enterprise implementation. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Knutson, Samuel Sent: Monday, January 13, 2020 8:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What is a mainframe? In my opinion IBM helped to save the mainframe when they included a built-in highly performant TCP/IP stack in the operating system.Making the mainframe a more mainstream hardware server and more importantly a mainstream software server that communications, API implementations and development practices as any other makes it viable for another 50 years. The alternative path was for it to become a truly niche isolated platform or for this core capability to be supplied by third party software. We saw that same evolution on other platforms if anyone remembers "Trumpet Winsock"😊 The mainframe remains the most securable platform today. z/OS in particular handles TCP/IP in a securable way allowing very granular controls of which application containers can connect to which ports. IBM has a published integrity policy which is applicable to the entire OS including TCP/IP. The most concerning security problems on the mainframe are not caused by TCP/IP but by Apathy, laziness, false confidence and ignorance. OEM TCP/IP stacks would have provided this capability and already were when IBM introduced TCP/IP in z/OS. You can make a reasoned argument that by incorporating TCP/IP as part of the operating system IBM has insured it has security and integrity equal to the balance of the operating system. Best Regards, Sam Knutson -Original Message- From: IBM Mainframe Discussion List On Behalf Of z/OS scheduler Sent: Saturday, January 11, 2020 3:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What is a mainframe? Welll, in my opinion the mainframe died when IBM allowed tcpip on their servers. From that point onwards it just became another server that could be hacked via TCPIP ports. James O'Leary Op vr 10 jan. 2020 om 21:05 schreef Steve Smith : > Well, it is Friday: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > youtube.com%2Fwatch%3Fv%3Dd0-pLcgq-2M&data=02%7C01%7CSamuel.Knutso > n%40COMPUWARE.COM%7C609bd2dd893148044b3a08d796d83cc4%7C893e9ba31b7844d > 8aca9105fab957fed%7C0%7C0%7C637143727850910523&sdata=qQqJNcO62gXdN > DUZwk8U0IjSGLtPFgD4dlS2pJIQdY8%3D&reserved=0 > > It's also about a bank :-) > > -- > sas > > -- > 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 The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it -- 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: MIPS chart for all IBM hardware model
You can see it on the IBM site (search -SRM Constant ). You should also see it in the Planning WLM manual, I believe Appendix B MIPS do NOT exist, and are simply made up numbers.They are a loose conglomeration that is similar to ITR. (where a 370/158 is considered a 1 MIPS machine). The concept simply doesn't exist in today's systems so that anyone claims it represents something, I would really like to hear the basis for their belief and evidence. G. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA OPS/MVS
If you don't mind, please forward them to me. I do work with CA customers and would be interested in what you have Thanks Gerhard -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter X. DeFabritus Sent: Friday, March 29, 2019 2:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CA OPS/MVS I would prefer to send an individual email of the files to anyone who wants this function. -- 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: Rebuilding IODF
I'm confused. How is anything running? What about other LPARs? Sent from my iPhone > On Jun 17, 2018, at 11:52 PM, Mainframe Sysprog > wrote: > > Thanks for the suggestions, will suggest these, and post further updates as > I get them. > > The IODF version that he has found so far is five years old!!. So, can't > rely on that. He has been supporting the environment from last 2 years only > so he is not aware of all the major changes that have happened. > > >> On Sun, Jun 17, 2018 at 6:13 PM, Rob Schramm wrote: >> >> I would give the Autodiscovery a try. How old is the version of the iodf >> that you still have? Could use an old one as a starting point. >> >> I am hoping the environment is not complicated. >> >> Rob Schramm >> >> >> >> On Sun, Jun 17, 2018, 8:12 AM Mainframe Sysprog < >> mainframe.sysp...@gmail.com> >> wrote: >> >>> A colleague has run into an issue where the VOLUME where the IODF resided >>> has been "reclaimed" from another shared system with no recent available >>> backups of IODF available to restore. >>> >>> They have a very old backup version from which he would be recovering the >>> IODF but is not sure how to get it back to the current live environment >> and >>> ensure consistency. >>> >>> Any thoughts? >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> -- >> >> Rob Schramm >> >> -- >> 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
Re: Use of dynamic system symbols in JCL
I don't see what the issue is. It simply says that if you code a DSN as a symbol and it is not resolved, then the symbol name itself becomes the temporary DSN I'm not clear on why anyone would care about this behavior? Sent from my iPhone > On Jun 10, 2018, at 2:15 PM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On Sat, 9 Jun 2018 16:13:34 -0700, Gerhard Adam wrote: >> >> This is the JCL Reference for z/OS 2.3 (page 183) >> >> Note: >> 1. In general, the system treats a single ampersand (&) followed by a >> character string of 1 to 8 characters as a symbolic parameter. (See “Using >> system symbols and JCL symbols” on page 38.) However, if you code a data set >> name as a symbolic parameter (by coding DSNAME=&), and do not assign >> a value to or nullify the symbolic parameter, the system will process it as >> a temporary data set name. > Yes. Thanks. And the previous page, Op. cit. 182: > > Data set name for temporary data set >... > When you use DSNAME for a temporary data set, code the name as two ampersands > (&&) followed by a character string 1 to 8 characters in length: > o The first character following the ampersands must be alphabetic or > national.. > o The remaining characters must be alphanumeric or national. > The more I think about this, the less I like it. The Ref. gives a couple > examples > in lieu of a formal rule, leaving it to the clever reader to infer that rule. > There's > been much stumbling toward that ojective in this thread with statements such > as, "This seems to work, but I can't tell why." > > Rather, I'd omit the "Note:" as quoted. That information appears elswhere > the Ref. > and needn't appear redundantly here. Rather, page 182 should say: > > Data set name for temporary data set >... > When you use DSNAME for a temporary data set, the equivalent JCL after symbol > substitution (as described on page 45, "Determining equivalent JCL") should be > a single ampersand (&) followed by a character string 1 to 8 characters in > length: > o The first character following the ampersands must be alphabetic or national. > o The remaining characters must be alphanumeric or national. > > This covers cases not currently described such as: >// SET TEMP='Who cares, anyway?' >// SET TTT='&TEMP' >//SYSUT2 DD DSN=&TTT,... > > -- gil > > -- > 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: Use of dynamic system symbols in JCL
Sure. From the JCL manual; DSNAME parameter This is the JCL Reference for z/OS 2.3 (page 183) Note: 1. In general, the system treats a single ampersand (&) followed by a character string of 1 to 8 characters as a symbolic parameter. (See “Using system symbols and JCL symbols” on page 38.) However, if you code a data set name as a symbolic parameter (by coding DSNAME=&), and do not assign a value to or nullify the symbolic parameter, the system will process it as a temporary data set name. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Saturday, June 9, 2018 3:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Use of dynamic system symbols in JCL On 6/9/2018 2:49 PM, Gerhard Adam wrote: > Actually it is documented as well as using double ampersands for symbols > (deferred usage) and the use of the ampersand as a part of the name. Citation, please... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 http://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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Use of dynamic system symbols in JCL
Actually it is documented as well as using double ampersands for symbols (deferred usage) and the use of the ampersand as a part of the name. Adam Sent from my iPhone > On Jun 9, 2018, at 11:24 AM, Ed Jaffe wrote: > >> On 6/6/2018 8:51 AM, Steve Smith wrote: >> This has been previously discussed. The main issue (as usual) is >> incompatibility with an ancient bug (or feature). Specifically, temporary >> dataset names such as DSN=&TMP. That's supposed to be DSN=&&TMP, but for >> whatever reason, the single-& version works, unless &TMP is a symbol. > > Wow! I confirmed this is an exposure! I never knew! > > IBM does not mention the single ampersand being valid temporary data set name > syntax in the description of the DSNAME parameter on the DD statement and I > have previously not seen it used that way. > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieab600/iea3b6_Syntax25.htm > > This reminds me of the rule in REXX where use of an uninitialized variable > results in the variable name itself being substituted. But, that is > documented behavior. This is just plain wrong. > > It might be a good use of the common tracker component (GTZ) to help identify > JCL with such errors. Otherwise, every new symbol added -- to the system, to > a proc, to anything that might have visibility to a job stream -- can lead to > unexpected JCL errors. > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > http://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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: empty KSDS behavior - why?
Perhaps a silly question, but were these files allocated with RECOVERY or SPEED? IIRC, RECOVERY pre-formats the first control area with binary zeros. In other words, does changing this specification change the behavior? Adam Sent from my iPhone > On May 29, 2018, at 3:12 PM, Frank Swarbrick > wrote: > > Test 1 - both DVFJS.DUMMY1 and DVFJS.DUMMY2 are "un-initialized" (HI-U-RBA is > 0): > > REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2) > IDC3300I ERROR OPENING DVFJS.DUMMY1 > IDC3351I ** VSAM OPEN RETURN CODE IS 160 > IDC0005I NUMBER OF RECORDS PROCESSED WAS 0 > IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12 > > Test 2 - after adding a record to DVFJS.DUMMY1, and then deleting the record > (HI-U-RBA is now 829440): > > REPRO IDS(DVFJS.DUMMY1) ODS(DVFJS.DUMMY2) > IDC0005I NUMBER OF RECORDS PROCESSED WAS 0 > IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 > > In this latter case DVFJS.DUMMY2 remains "un-initialized" (HI-U-RBA is still > 0). > > > From: IBM Mainframe Discussion List on behalf of > Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> > Sent: Tuesday, May 29, 2018 12:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: empty KSDS behavior - why? > >> On Tue, 29 May 2018 18:12:16 +, Seymour J Metz wrote: >> >> Why would IBM have to add a key? What is necessary is to create an empty >> KSDS that can be read; add and delete is one way to do it, and doesn't leave >> a key behind. I'd prefer that they just initialized it to have the same >> contents as adding and deleting. > Is the result identical whether the added/deleted record has key high-values, > low-values, or something > in between? > > And I'll repeat my question, what is the result of REPROing a properly > initialized > but currently empty KSDS? > > -- gil > > -- > 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
Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?
I personally used SMP in 1975 on a S/360 running MFT. Sent from my iPhone On May 23, 2018, at 8:29 PM, Edward Gould wrote: >> On May 23, 2018, at 2:13 PM, Gerhard Adam wrote: >> >> SMP was available in MVT and MFT. It did not begin with MVS > > I beg to differ. But I was new to the job and our senior sysprog did maint > with another IBM program (which I do not remember but it was NOT SMP but > something like iebptfle or something like that. > Someone else, please confirm. > > Ed > > > -- > 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: [External] Old School Maintenance Philosophy -- Never ACCEPT?
If I remember, the PTS still held the sysmods and the ACDS was for the distribution "zone" equivalent. Sent from my iPhone > On May 23, 2018, at 11:55 AM, Seymour J Metz wrote: > > The CDS may have been an equivalent to a target zone, but not to the entire > CSI. You won't get very far without a PTS and ACDS. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf of > Nims,Alva John (Al) > Sent: Wednesday, May 23, 2018 2:50 PM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? > > Yes, that was my mistake, I should have said the predecessor to the CSI was > the CDS, a PDS data set with that funny character in the member name. > > Al Nims > Systems Admin/Programmer III > UF Information Technology > East Campus > P.O. Box 112050 > Gainesville, FL. 32611 > (e) ajn...@ufl.edu > (p) (352) 273-1298 > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Wednesday, May 23, 2018 2:40 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? > >> On Wed, 23 May 2018 11:05:29 -0700, Gerhard Adam wrote: >> >> I think the reference may have been to the older SMP CDS which played >> the role of the current CSI >> > The rumor I heard (I wasn't there) is that, prior to VSAM, SMP used a PDS > directory as a makeshift data base. Names of members (which needn't actually > exist) were limited to 7 bytes in order that the eighth could be used for > flags. > > -- gil > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?
SMP was available in MVT and MFT. It did not begin with MVS Sent from my iPhone On May 23, 2018, at 11:50 AM, Edward Gould wrote: >> On May 23, 2018, at 9:08 AM, David L. Craig wrote: >> >>> >>> Not sure how long ago eons was, but I started in the >>> mid-80s on MVS/SP and at my first SMP/E (and I believe >>> only) class, I was taught the APPLY / run for a while / >>> ACCEPT usage - except for USERMODs or APARs that hadn't >>> had a published PTF yet. >> >> I learned to use SMP back on MVT (am I the only one still >> here that can truthfully make that statement?) and while >> it's been a while since I last used SMP/E, I do not recall >> ever encountering a no ACCEPT policy for any IBM MRM. >> But people aren't mentioning policy for archiving snapshots >> of target and DLIB volumes and restoring therefrom--much >> faster than reAPPLYing LOTS of maintenance. That also >> requires tracking the target/DLIB volume snapshot >> associations, which are not necessarily based upon the >> dates of the snapshots. > > AFAIK smp (e) did not exist during mvs 2.0 3.0(shakes on this one) and it > came out with 3.7 (?) > Before smp there was tremendous and I do mean tremendous working by having to > manually to the co, prerec's by hand. It was drudge work that needed a high > amount of concentration and immersion. > I did it once and couldn’t handle the long hours needed. We printed a > spreadsheet and it helped a little but still took copious amounts of time. > SMP was a godsend to sysprogs. I would venture to say that MVS would have > ended up in the dust pile for computer history without SMP. Yes it was > cumbersome and the PDS’s needed and large number of directories was a real > pain. VSAM saved SMP as well. > Ed > > > > > -- > 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: [External] Old School Maintenance Philosophy -- Never ACCEPT?
I think the reference may have been to the older SMP CDS which played the role of the current CSI Sent from my iPhone > On May 23, 2018, at 11:03 AM, Seymour J Metz wrote: > > The PTS, among others, was a PDS. SMP used very strange member names. There > was no CSI, no zones. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf of > Carmen Vitullo > Sent: Wednesday, May 23, 2018 1:11 PM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? > > CSI not VSAM ? > > > Carmen Vitullo > > - Original Message - > > From: "Alva John Nims (Al)" > To: IBM-MAIN@LISTSERV.UA.EDU > Sent: Wednesday, May 23, 2018 12:00:11 PM > Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? > > " I learned to use SMP back on MVT (am I the only one still here that can > truthfully make that statement?)" Answer: No, yes I remember SMP back before > the "e" was added on, the CSI was a PDS! And not a PDSe! > > I do not follow the 'Never ACCEPT" process. > > Al Nims > Systems Admin/Programmer III > UF Information Technology > East Campus > P.O. Box 112050 > Gainesville, FL. 32611 > (e) ajn...@ufl.edu > (p) (352) 273-1298 > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of David L. Craig > Sent: Wednesday, May 23, 2018 10:09 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? > >> On 18May23:1247+, Pommier, Rex wrote: >> >> Not sure how long ago eons was, but I started in the mid-80s on MVS/SP >> and at my first SMP/E (and I believe >> only) class, I was taught the APPLY / run for a while / ACCEPT usage - >> except for USERMODs or APARs that hadn't had a published PTF yet. > > I learned to use SMP back on MVT (am I the only one still here that can > truthfully make that statement?) and while it's been a while since I last > used SMP/E, I do not recall ever encountering a no ACCEPT policy for any IBM > MRM. > But people aren't mentioning policy for archiving snapshots of target and > DLIB volumes and restoring therefrom--much faster than reAPPLYing LOTS of > maintenance. That also requires tracking the target/DLIB volume snapshot > associations, which are not necessarily based upon the dates of the snapshots. > -- > > May the LORD God bless you exceedingly abundantly! > > Dave_Craig__ > "So the universe is not quite as you thought it was. > You'd better rearrange your beliefs, then. > Because you certainly can't rearrange the universe." > __--from_Nightfall_by_Asimov/Silverberg_ > > -- > 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 > > -- > 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: [External] Old School Maintenance Philosophy -- Never ACCEPT?
Sorry, but the CSI was never a PDS and still isn't. I suspect you're thinking of the PTS Sent from my iPhone > On May 23, 2018, at 10:00 AM, Nims,Alva John (Al) wrote: > > " I learned to use SMP back on MVT (am I the only one still here that can > truthfully make that statement?)" Answer: No, yes I remember SMP back before > the "e" was added on, the CSI was a PDS! And not a PDSe! > > I do not follow the 'Never ACCEPT" process. > > Al Nims > Systems Admin/Programmer III > UF Information Technology > East Campus > P.O. Box 112050 > Gainesville, FL. 32611 > (e) ajn...@ufl.edu > (p) (352) 273-1298 > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of David L. Craig > Sent: Wednesday, May 23, 2018 10:09 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? > >> On 18May23:1247+, Pommier, Rex wrote: >> >> Not sure how long ago eons was, but I started in the mid-80s on MVS/SP >> and at my first SMP/E (and I believe >> only) class, I was taught the APPLY / run for a while / ACCEPT usage - >> except for USERMODs or APARs that hadn't had a published PTF yet. > > I learned to use SMP back on MVT (am I the only one still here that can > truthfully make that statement?) and while it's been a while since I last > used SMP/E, I do not recall ever encountering a no ACCEPT policy for any IBM > MRM. > But people aren't mentioning policy for archiving snapshots of target and > DLIB volumes and restoring therefrom--much faster than reAPPLYing LOTS of > maintenance. That also requires tracking the target/DLIB volume snapshot > associations, which are not necessarily based upon the dates of the snapshots. > -- > > May the LORD God bless you exceedingly abundantly! > > Dave_Craig__ > "So the universe is not quite as you thought it was. > You'd better rearrange your beliefs, then. > Because you certainly can't rearrange the universe." > __--from_Nightfall_by_Asimov/Silverberg_ > > -- > 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
Re: Old School Maintenance Philosophy -- Never ACCEPT?
Why bother? Do a RESTORE GROUP CHECK and get that information. Sent from my iPhone > On May 23, 2018, at 9:08 AM, Tom Marchant > <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > >> On Wed, 23 May 2018 10:07:16 -0400, John Eells wrote: >> >> As others have pointed out, it makes RESTORE a lot harder if you never >> ACCEPT PTFs. > > I haven't had the need to do this yet, but I have an idea that I think will > make it much easier. > > If I want to restore PTF A and RESTORE CHECK tells me that it can't > RESTORE it because PTFs B, C, and D have not been ACCEPTed, I can > run ACCEPT CHECK on B, C, and D. That should give me a list of all the > PTFs that also need to be RESTOREd in order to RESTORE A. > > -- > Tom Marchant > > -- > 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: [External] Old School Maintenance Philosophy -- Never ACCEPT?
I also don't recall a "never ACCEPT" policy. That would be silly because it becomes a "never RESTORE" policy. Sent from my iPhone > On May 23, 2018, at 7:08 AM, David L. Craig wrote: > >> On 18May23:1247+, Pommier, Rex wrote: >> >> Not sure how long ago eons was, but I started in the >> mid-80s on MVS/SP and at my first SMP/E (and I believe >> only) class, I was taught the APPLY / run for a while / >> ACCEPT usage - except for USERMODs or APARs that hadn't >> had a published PTF yet. > > I learned to use SMP back on MVT (am I the only one still > here that can truthfully make that statement?) and while > it's been a while since I last used SMP/E, I do not recall > ever encountering a no ACCEPT policy for any IBM MRM. > But people aren't mentioning policy for archiving snapshots > of target and DLIB volumes and restoring therefrom--much > faster than reAPPLYing LOTS of maintenance. That also > requires tracking the target/DLIB volume snapshot > associations, which are not necessarily based upon the > dates of the snapshots. > -- > > May the LORD God bless you exceedingly abundantly! > > Dave_Craig__ > "So the universe is not quite as you thought it was. > You'd better rearrange your beliefs, then. > Because you certainly can't rearrange the universe." > __--from_Nightfall_by_Asimov/Silverberg_ > > -- > 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: WLM?
Bear in mind that regardless of the goals (in other words you don't know that a velocity of 40% won't give you a response time of .5 seconds). The essential metric is the importance level. In period 3, you are essentially saying that when your system gets busy, Infoprint simply isn't that important to help meet its goals. The change from Importance 3 to Importance 5 shifts the degree to which WLM will help the service class period in meetings its goals. Adam Sent from my iPhone > On May 3, 2018, at 12:27 PM, David Betten wrote: > > I would suggest looking at an RMF workload activity report to see what the > workload is doing now rather than arbitrarily changing period durations and > goals. The workload activity report can tell you the average response time > and transactions rates, along with the service units and velocity as it's > performing now. Based on that, you should then be able to set some > reasonable period durations and goals. > > > Have a nice day, > Dave Betten > z/OS Performance Specialist > Cloud and Systems Performance > IBM Corporation > email: bet...@us.ibm.com > 1-720-396-3882 > > IBM Mainframe Discussion List wrote on > 05/03/2018 03:14:40 PM: > >> From: "Adams, Anne (DTI)" >> To: IBM-MAIN@LISTSERV.UA.EDU >> Date: 05/03/2018 03:15 PM >> Subject: Re: WLM? >> Sent by: IBM Mainframe Discussion List >> >> Omg ... my bad. I get it now. I'll just go over and stand by the >> truck. Thanks. >> >> Anne R. Adams, CISSP >> DTI, Systems Engineering >> Lead Mainframe Services Analyst >> 302.739.9500 >> >> We support the mainframe, it just works. >> >> >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Jackson, Rob >> Sent: Thursday, May 03, 2018 2:58 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: WLM? >> >> On our tiny mainframe 800 SUs is still only .03 CPU seconds, which >> is not insignificant, but is really not that much CPU time. 800 SUs >> is just not that much CPU. >> >> First Tennessee Bank >> Mainframe Technical Support >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Adams, Anne (DTI) >> Sent: Thursday, May 03, 2018 2:35 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: WLM? >> >> [External Email] >> >> I understand the words in your response but I still don't >> understand. How is it possible that it takes over 800 SUs to respond >> to and Infoprint daemon? What am I missing here? >> >> Anne R. Adams, CISSP >> DTI, Systems Engineering >> Lead Mainframe Services Analyst >> 302.739.9500 >> >> We support the mainframe, it just works. >> >> >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Gerhard Adam >> Sent: Thursday, May 03, 2018 2:20 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: WLM? >> >> The first two periods are ALWAYS used, but the duration limits how >> long the work stays there before it transitions into the next period. >> >> So, if most of our work is in period 3, it's because it has exceeded >> the 800 SU's that have been designated in the previous periods. >> >> Adam >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU >> ] On Behalf Of Adams, Anne (DTI) >> Sent: Thursday, May 3, 2018 10:24 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: WLM? >> >> Question for any WLM/performance geniuses, >> >> Our Inforprint processes suffer when the system gets slow and >> therefore print slows. The Infoprint manual suggests changing the >> WLM Service Class for these processes thusly: >> >> * Service Class OMVSDMN - OMVS Print Daemons >> >> Base goal: >> CPU Critical = NOI/O Priority Group = NORMAL >> >># Duration Imp Goal description >>- - - >>1 200380% complete within 00:00:00.500 >>2 600460% complete within 00:00:01.000 >>3 5Execution velocity of 40 >> >> It's that last period that has us confused. It appears that the >> first two periods are never attempted and everything falls into the >> third one (which is not what we want, we want the first one). Should >> the third one be more like the first two? >> >> Anne R. Adams, CISSP &g
Re: WLM?
BTW, the reason your Infoprint work suffers is most likely due to it having an Importance level of 5. If you make that higher, then it should ensure that Infoprint gets serviced by WLM to ensure its goals are being met [regardless of the velocity or response time settings]. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Adams, Anne (DTI) Sent: Thursday, May 3, 2018 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: WLM? Question for any WLM/performance geniuses, Our Inforprint processes suffer when the system gets slow and therefore print slows. The Infoprint manual suggests changing the WLM Service Class for these processes thusly: * Service Class OMVSDMN - OMVS Print Daemons Base goal: CPU Critical = NOI/O Priority Group = NORMAL # Duration Imp Goal description - - - 1 200380% complete within 00:00:00.500 2 600460% complete within 00:00:01.000 3 5Execution velocity of 40 It's that last period that has us confused. It appears that the first two periods are never attempted and everything falls into the third one (which is not what we want, we want the first one). Should the third one be more like the first two? Anne R. Adams, CISSP DTI, Systems Engineering Lead Mainframe Services Analyst 302.739.9500 We support the mainframe, it just works. -- 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: WLM?
The first two periods are ALWAYS used, but the duration limits how long the work stays there before it transitions into the next period. So, if most of our work is in period 3, it's because it has exceeded the 800 SU's that have been designated in the previous periods. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Adams, Anne (DTI) Sent: Thursday, May 3, 2018 10:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: WLM? Question for any WLM/performance geniuses, Our Inforprint processes suffer when the system gets slow and therefore print slows. The Infoprint manual suggests changing the WLM Service Class for these processes thusly: * Service Class OMVSDMN - OMVS Print Daemons Base goal: CPU Critical = NOI/O Priority Group = NORMAL # Duration Imp Goal description - - - 1 200380% complete within 00:00:00.500 2 600460% complete within 00:00:01.000 3 5Execution velocity of 40 It's that last period that has us confused. It appears that the first two periods are never attempted and everything falls into the third one (which is not what we want, we want the first one). Should the third one be more like the first two? Anne R. Adams, CISSP DTI, Systems Engineering Lead Mainframe Services Analyst 302.739.9500 We support the mainframe, it just works. -- 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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)
It seems your picking a fight that doesn't exist. The IRS, has not had a problem complying with the tax code, nor in processing returns. Software was clearly changed and capable of doing what was needed. COBOL was never intended to interface directly with networking software so it was no more suited for IP than it was for SNA. Those services were provided by subsystems like CICS for which COBOL still works. I have no idea of why you think customers care about COBOL skills. The issue I have, is that all the complaining about IBM seems to overlook one important fact. It is IBM that enables companies to preserve their investment in code that was developed and is still running 40 years later. When *nix and Windows systems can do some comparable, then there might be something to discuss. At present, they can't even assure a program's operation between releases let alone over decades of use. Sent from my iPhone > On Apr 20, 2018, at 3:26 PM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On Fri, 20 Apr 2018 19:25:54 +, Lester, Bob wrote: >> >> I agree with both you and Gil. But, how many programmers in the 60s, 70s, >> even 80s were thinking about Y2K? Sure, the really good ones were, but what >> about the other 80%? >> >> and, Y2K came off without a hitch...(FSVO - "hitch")😊 > > >> -Original Message- >> From: IBM Mainframe Discussion List Porowski, Kenneth >> Sent: Friday, April 20, 2018 1:20 PM >> >> That was due to lack of foresight by the programmer not due to the age of >> the system. > True in the sense that it affected one-year-old computers as much as older > computers > running th same software. > > I'm disappointed that this thread has so much focused on Y2K which I meant > only as > an extreme example. Things change. Y2K was only more precisely forseeable. > > Increasing complexity of the tax code requires new logic. Inflation and rate > escalation > may have made some data fields inadequate in size. E-filing requires network > interfaces > and code to support them and causes the one-day spike in workload. I gather > from > these fora that COBOL is not comfortably suited to TCP/IP. IBM bet that > SNA/VTAM > could crush TCP/IP and customers were the losers. IBM bet that EBCDIC could > crush > ASCII and customers were the losers. And customers bet that COBOL skills > would remain > in the forefront of availability. > > -- gil > > -- > 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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)
It was discussed, but the general feeling was that those systems would have been rewritten or replaced long before it became an issue. No one expected applications to be running 30-40 years after they were first implemented. Sent from my iPhone > On Apr 20, 2018, at 12:25 PM, Lester, Bob wrote: > > > I agree with both you and Gil. But, how many programmers in the 60s, 70s, > even 80s were thinking about Y2K? Sure, the really good ones were, but what > about the other 80%? > > and, Y2K came off without a hitch...(FSVO - "hitch")😊 > > I love Fridays... > > BobL > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Porowski, Kenneth > Sent: Friday, April 20, 2018 1:20 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New > Hardware (nextgov.com) [ EXTERNAL ] > > That was due to lack of foresight by the programmer not due to the age of the > system. > > > > This email message and any accompanying materials may contain proprietary, > privileged and confidential information of CIT Group Inc. or its subsidiaries > or affiliates (collectively, “CIT”), and are intended solely for the > recipient(s) named above. If you are not the intended recipient of this > communication, any use, disclosure, printing, copying or distribution, or > reliance on the contents, of this communication is strictly prohibited. CIT > disclaims any liability for the review, retransmission, dissemination or > other use of, or the taking of any action in reliance upon, this > communication by persons other than the intended recipient(s). If you have > received this communication in error, please reply to the sender advising of > the error in transmission, and immediately delete and destroy the > communication and any accompanying materials. To the extent permitted by > applicable law, CIT and others may inspect, review, monitor, analyze, copy, > record and retain any communications sent from or received at this email > address. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Friday, April 20, 2018 3:13 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day Due to > New Hardware (nextgov.com) > >> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote: >> >> Applications don't get old. They either do what they're supposed to do or >> they don't. It has nothing to do with age. > Remember Y2K? > > -- gil > > -- > 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 > > This e-mail transmission may contain information that is proprietary, > privileged and/or confidential and is intended exclusively for the person(s) > to whom it is addressed. Any use, copying, retention or disclosure by any > person other than the intended recipient or the intended recipient's > designees is strictly prohibited. If you are not the intended recipient or > their designee, please notify the sender immediately by return e-mail and > delete all copies. OppenheimerFunds may, at its sole discretion, monitor, > review, retain and/or disclose the content of all email communications. > > > -- > 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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)
Y2k had nothing to do with age. It had to do with what applications did or didn't do. If they had been written with 4 digit years they could have been written in 1964 and had no date issues. It wasn't like a LA instruction suddenly showed signs of age. Sent from my iPhone > On Apr 20, 2018, at 12:13 PM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote: >> >> Applications don't get old. They either do what they're supposed to do or >> they don't. It has nothing to do with age. > Remember Y2K? > > -- gil > > -- > 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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)
Applications don't get old. They either do what they're supposed to do or they don't. It has nothing to do with age. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Smith, Nathan (ATLANTA, GA) Sent: Friday, April 20, 2018 6:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com) Why do people seem to ignore the fact that UNIX and the C Programming Language were being developed in 1969 and being used in the early '70s (thanks Bell Labs!)? I don't see the mad rush to do away with *nix-based systems or applications written in C because they're "old". Just because an application is "old" doesn't mean it's not being updated and enhanced. Anthem, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)
Well, it's rather obvious that the people that wrote this article are about as ignorant as they come. Sent from my iPhone > On Apr 19, 2018, at 3:47 PM, Nash, Jonathan S. > <01abdcef2f3c-dmarc-requ...@listserv.ua.edu> wrote: > > IRS - 60-Year-Old IT System Failed on Tax Day > Due to New Hardware > > By Aaron Boyd and Frank Konkel > April 19, 2018 06:02 PM > > https://www.nextgov.com/it-modernization/2018/04/irs-60-year-old-it-system-failed-tax-day-due-new-hardware/147598/ > > Congress and watchdogs have been warning the IRS to upgrade > its systems for years. > > The Internal Revenue Service attributed the agency’s Tax Day > crash to a piece of hardware supporting an IT system that is > almost 60 years old. > > Called the Individual Master File, components of the system - > including 20 million lines of computer code—date back to 1960, > when John F. Kennedy was president. > > IRS told Nextgov 18-month-old hardware supporting the > Individual Master File experienced a caching issue causing > the system to fail. The failure disrupted almost all other > services and systems IRS provides because those systems > ingest data from the Individual Master File. When those > systems—such as Direct Pay and the structured payments > portal—called to the Individual Master File mainframe and > got no response, they too failed. > > Despite repeated warnings from the Government Accountability > Office and Congress, IRS plans to modernize the system are > at least six years behind schedule and several hundred > million dollars over budget. > > This was our biggest fear about one of these > mission-critical systems crashing, Dave Powner, GAO's > director of IT management issues, told Nextgov Thursday. > Fortunately, it wasn't down for a long period of time, so > in that way, we dodged a bullet. > > Still, the crash forced the IRS to extend the tax filing > deadline one day, delaying some 14 million submissions. It > could be several years before the Individual Master File is > fully modernized and rid of 1960s-era technology. > > To address the risk of a system failure, the IRS has a plan > to modernize two core components of the IMF by 2021, > followed by a year of parallel validation before retiring > those components in 2022,” the IRS told Nextgov in March, > before the crash occurred. That timeline could slip because > the IRS says it needs to hire at least 50 additional > employees—while backfilling any attrition—plus an additional > $85 million per year in annual non-labor funding over the > next five years. The president’s fiscal 2018 budget request > called for a $239 million reduction in funding for the IRS, > which has faced numerous cuts in recent years. > > Since Republicans gained control of the House of > Representatives in 2010, their partisan attacks have left > the IRS with nearly 10,000 fewer customer service > representatives to assist taxpayers and a patchwork of IT > systems, some dating back to the Kennedy Administration, > which is ultimately harming all taxpayers,” Rep. Gerry > Connolly, D-Va., told Nextgov. > > However, the Republican-led House ratified a package of nine > IRS reform bills following the Tax Day crash that could amp > up IRS’ modernization efforts. The bills, including the > 21st-Century IRS Act and the Taxpayer First Act, will stress > improving the customer experience for taxpayers as well as > modernizing technology across the agency. The reform package > was ushered in by the House Ways and Means committee, > chaired by Rep. Kevin Brady, R-Texas. > > A new tax code calls for a new tax administrator, and we > have worked together so that the IRS can be transformed into > an agency with a singular mission: taxpayer first, Brady > said in a statement. > > One of the bills will require IRS to compile a plan to > enhance agency technology and customer service. That plan is > due to Congress by September. > > The Individual Master File contains data from 1 billion > taxpayer accounts dating back several decades and is the > chief IRS application responsible for receiving 100 million > Americans’ individual taxpayer data and dispensing refunds. > IRS first attempted to replace the system with a modernized > Customer Account Data Engine, but that effort was canceled > in 2009. A delivery date for CADE 2, the IRS’ subsequent > modernization effort, has slipped several years even as > contractors working on the project have earned as much as > $290 million. > > We still have not seen a solid plan in place, Powner told > Nextgov. GAO identified the Individual Master File as the > oldest technology system still operational in government in > 2016. > > -- > 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 / a
Re: The IRS Really Needs Some New Computers
Since I was actually in the IRS data center a few months ago, the idea of 30 year old technology is absurd. Sent from my iPhone > On Apr 17, 2018, at 1:22 PM, Ed Jaffe wrote: > >> On 4/17/2018 11:09 AM, Allan Staller wrote: >> The IRS has been trying to upgrade both hardware and software for at least >> 30 years I am aware of. >> It keeps getting shot down by Congress in the appropriations process. > > The IRS folks that attend SHARE from time-to-time (from Virginia?) seem to be > running the latest and greatest IBM Z hardware and peripherals. > > Having said that, there might be several different IRS data centers around > the country... > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > http://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 a 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The IRS Really Needs Some New Computers
Nonsense, the IRS is running Z/13's , etc. Sent from my iPhone > On Apr 17, 2018, at 11:09 AM, Allan Staller wrote: > > The IRS has been trying to upgrade both hardware and software for at least 30 > years I am aware of. > It keeps getting shot down by Congress in the appropriations process. > > The opposite of PROGRESS is CON.. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Tuesday, April 17, 2018 12:34 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: The IRS Really Needs Some New Computers > > Mostly historical: > > https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bloomberg.com%2Fview%2Farticles%2F2018-04-17%2Fthe-irs-computer-system-is-the-oldest-in-the-government&data=02%7C01%7Callan.staller%40HCL.COM%7C792c5b7241dd415a210308d5a48970ff%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636595832636753536&sdata=P6KLIEcmkgNFa4lZeymrTbaQ4XCmyBNo13loxSL1%2F9k%3D&reserved=0 > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > -- > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses > in transmission. The e mail and its contents (with or without referred > errors) shall therefore not attach any liability on the originator or HCL or > its affiliates. Views or opinions, if any, presented in this email are solely > those of the author and may not necessarily reflect the views or opinions of > HCL or its affiliates. Any form of reproduction, dissemination, copying, > disclosure, modification, distribution and / or publication of this message > without the prior written consent of authorized representative of HCL is > strictly prohibited. If you have received this email in error please delete > it and notify the sender immediately. Before opening any email and/or > attachments, please check them for viruses and other defects. > -- > > -- > 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: Many arguments to a Rexx function call
I also wasn't aware of the limit until I tried it. Since the question raised involved continuation, I simply tried the function with fewer operands but including continuation. When that worked, it was simply a matter of adding the others in until it failed. Frankly, I came across the 20 argument limit simply by trying it out. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jantje. Sent: Tuesday, April 10, 2018 3:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Many arguments to a Rexx function call On Mon, 9 Apr 2018 14:31:18 -0700, Gerhard Adam wrote: >Just seems like a lot of discussion trying to pass 22 arguments, when the >limit is 20. > You're right. Only, as I was not aware of the existence of that limit... >After that it's merely a question of how you can convey the information using >whatever means you have available. > I am using now a different separator character (one I am rather sure will never occur in the value of the arguments to pass), glueing all arguments together into one and parsing them back out in the invoked function. That does the trick. Cheers, Jantje. -- 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: Many arguments to a Rexx function call
Just seems like a lot of discussion trying to pass 22 arguments, when the limit is 20. After that it's merely a question of how you can convey the information using whatever means you have available. Sent from my iPhone > On Apr 9, 2018, at 12:41 PM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On Mon, 9 Apr 2018 09:29:22 -0700, Gerhard Adam wrote: >> >> If you need to include all 22 arguments, just make the last one bigger and >> parse it a second time to get the results. >> For example: >> 01 /* REXX */ >> >> 02 rs = ALERTSN(SEV,TYPENAME,ELEMENT,DESC,STATUS,STSDESC,, >> >> 03 SUBSRC,SOURCE,LOCATION,SYSTYPE,PLTFTYPE,IMPACT,HOST,, >> >> 04 MONENV,RESOURCE,EXTRINFO,ACTIVE,CLOSING,FTPERR,, >> >> 05 APPLTYPE APPLNAME UNIQUE) >> >> 06 EXIT 0 >> >> ... >> Notice that the last argument is separated by spaces to combine them all as >> a single argument. > This depends on a couple things: > o That ALERTSN is written in Rexx, or at least that the OP has the source so > he > can modify it. > o That the "combined" arguments contain no internal blanks, which makes > parsing > more complicated. > > -- gil > > -- > 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: Many arguments to a Rexx function call
If you need to include all 22 arguments, just make the last one bigger and parse it a second time to get the results. For example: 01 /* REXX */ 02 rs = ALERTSN(SEV,TYPENAME,ELEMENT,DESC,STATUS,STSDESC,, 03 SUBSRC,SOURCE,LOCATION,SYSTYPE,PLTFTYPE,IMPACT,HOST,, 04 MONENV,RESOURCE,EXTRINFO,ACTIVE,CLOSING,FTPERR,, 05 APPLTYPE APPLNAME UNIQUE) 06 EXIT 0 07 ALERTSN: 08 SAY ARG() 09 SAY ARG(1) 10 SAY ARG(5) 11 SAY ARG(9) 12 SAY ARG(10) 13 SAY ARG(15) 14 SAY ARG(20) Notice that the last argument is separated by spaces to combine them all as a single argument. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jantje. Sent: Monday, April 09, 2018 9:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Many arguments to a Rexx function call On Mon, 9 Apr 2018 09:37:20 -0400, Phil Smith III wrote: >Then you're apparently calling it wrong. I see double commas in the >error >output: that suggests you have doubled commas in the wrong place, >because if they're seen as continuation, ALERTSN won't see them at all. Well... ALERTSN is not seeing any of it. The error message is emitted while ALERTSNB is in control. ALERTSN is never invoked. Cheers, Jantje. -- 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: Many arguments to a Rexx function call
Normal continuation rules would apply, but it appears that there is a limit of 20 arguments. You have 22, which produces the error Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith III Sent: Friday, April 6, 2018 3:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Many arguments to a Rexx function call Don Grinsell wrote: >Start your continuation lines with a comma: > RS=ALERTSN(SEV,TYPENAME,ELEMENT,DESC,STATUS,STSDESC , > ,SUBSRC,SOURCE,LOCATION,SYSTYPE,PLTFTYPE,IMPACT,HOST , > ,MONENV,RESOURCE,EXTRINFO,ACTIVE,CLOSING,FTPERR , > ,APPLTYPE,APPLNAME,UNIQUE) Ooh. Never even thought of that! hmm, but that only works for continued function/subroutine calls, since that leading comma is the one serving as the argument delimiter. Well, ok, so combine the techniques-make the continuation comma have a space before it: RS=ALERTSN(SEV,TYPENAME,ELEMENT,DESC,STATUS,STSDESC , ,SUBSRC,SOURCE,LOCATION,SYSTYPE,PLTFTYPE,IMPACT,HOST , ,MONENV,RESOURCE,EXTRINFO,ACTIVE,CLOSING,FTPERR , ,APPLTYPE,APPLNAME,UNIQUE) Then you can still find the continuations, but it avoids the fugly 'comma space comma'. I learn something every day (I hope)! -- 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: WLM and Dispatching Priority
Agreed. That's not a problem and with multiple service classes, one would expect multiple dispatching priorities to be assigned to the enclaves. However, that suggests that when the address space is displayed, such considerations shouldn't matter. We aren't displaying the enclave or any other unit of work. If we display the address space, then only the address space service class and dispatching priority should be shown. If those are different, then it suggests a problem with the display. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gabriel Tully Sent: Friday, April 6, 2018 4:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WLM and Dispatching Priority But the address space can be servicing multiple enclaves with different service classes. Granted that the DP is generally adjusted to the highest goal, but it's a moving target that would lead to inaccuracies. Thanks, Gabe -- 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: WLM and Dispatching Priority
Thanks. That helps. However, doesn't that now suggest that the monitor's display is actually wrong? In other words, I would expect that if a monitor was going to display a dispatching priority, it would also display the service class with which it was associated. It would be erroneous to report on a service class and include a dispatching priority from a unit of work that was running in a different service class. I would expect more consistency than that. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: Thursday, April 5, 2018 11:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WLM and Dispatching Priority A DB2 WLM Stored Procedures server address space might well show up as being in a service class. However, it - with its peers - supports a Service Class / Application Environment combination with a queue of work. The queue of work is EXCLUSIVELY that with the Service Class and also the Application Environment stated. The work executes at that Service Class' goal, not the server address space's Service Class goal. (I wrote the Server Address Space Management chapters in the 2003/4 Redbook "DB2 Stored Procedures: Through The Call And Beyond" - and did quite a bit of research and client work in this very area.) Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id112794357 3?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Gerhard Adam To: IBM-MAIN@LISTSERV.UA.EDU Date: 05/04/2018 18:49 Subject:Re: WLM and Dispatching Priority Sent by:IBM Mainframe Discussion List I don't understand what you're trying to say. Enclaves are certainly assigned to service classes and can be reset or even quiesced. From the ENC display in SDSF NAMESSType StatusSrvClass Per 240002 STCINACTIVE SYSSTC 1 4C000C STCACTIVE SRVHIM 1 700015 STCINACTIVE SRVHIM 1 380007 STCACTIVE SRVHIM 1 48000B STCINACTIVE SRVHIM 1 5D STCACTIVE SRVHIM 1 680013 STCINACTIVE SRVHIM 1 340006 STCACTIVE SRVHIM 1 44000A STCINACTIVE SRVHIM 1 600011 STCACTIVE SRVHIM 1 640012 STCINACTIVE SRVHIM 1 49 STCACTIVE SRVHIM 1 58000F STCINACTIVE SRVHIM 1 5C0010 STCACTIVE SRVHIM 1 6C0014 STCINACTIVE SRVHIM 1 3C0008 STCACTIVE SRVHIM 1 54000E STCINACTIVE SRVHIM 1 I specifically don't understand what you mean by service classes not being applicable to server address spaces. How can any address space that is associated with a service class, not be managed to that service class' goals? It would have to be identifiable as a separate internal service class, but whatever the reason, it would have to be something that can be specifically seen and tracked using the Type 99 data. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, April 5, 2018 9:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WLM and Dispatching Priority On Thu, 5 Apr 2018 08:37:20 -0700, Gerhard Adam wrote: >I don't see the relevance of enclaves or anything else in this. It is >the service class period that matters. That is only one factor. Transaction response time goals are another factor. > >So, if I assigned DB2, enclaves, TSO, and batch to the same service >class, You don't assign an enclave to a service class. WLM defines enclaves based upon transaction response time goals and the address spaces that are involved in those transactions. Those server address spaces are managed to meet the goals of the transactions that include that address space in their enclave(s). This can get complicated because many different transactions with different requirements and involving different address spaces can be in different enclaves that involve an address space. WLM does not change the service class of those server address spaces, but it no longer manages them based on their service class. It wouldn't make any sense to change the service class of the DB2 region to match the service class of a CICS transaction whose enclave requires the DP of the DB2 region to change. At least, that's the way I understand it. >they should still all have the same dispatching
Re: WLM and Dispatching Priority
My dispute about the dispatching priorities comes from the Type 99 subtype 1 records.I've included the data from a report that shows that the dispatching priority changes [including the projected changes afterwards] are all based on the entire service class. In this case, it clearly shows that WLM is making the assessment and increasing the receiver's dispatching priority. You can see how WLM took the initial value at dispatching priority 247 and combined that with 251 to arrive at the new projected value. Whether SRM is the specific mechanism that makes that change isn't important here. 167 233 ONLTST 1 1.00 1.27 270 PA - Receiver candidate selected 167 233 SERVERS 1 11.66 2.59 308 PA - Donor period 167 233 SERVERS 1 11.66 2.59 880 PA - Processor donor selected 167 233 ONLTST 1 1.00 1.27 620 PA - Assess moving receiver up to occupied priority 167 233 ONLTST 1.96 1.25 750 PA - Increase receiver priority 167 233 SERVERS 1 14.00 2.59 940 PA - Unchanged donor Priority Table Report: Numbers as indicated are "at priority" DP AfterUtilizationCPU Samples Wait to Cumulative Utilization Avg MTTW (SU/sec) Used (SU/sec) PA Unbunching Init Proj Using Delay Using Ratio Init Projected Achievable Initial Projected Actual Projected --- 19220.7% 20.7% 6 25 4 134.3% 134.3% .0% 3.6 3.6 8302.1 8302.1 231 3.2%3.2% 0 1 1 113.6% 113.6% .0% 4.0 4.0 258.1258.1 23361.8% 61.8% 45 24 1 110.4% 110.4% .0% 12.7 12.7 5930.0 5930.0 235 .8% .8% 0 0 1 48.6% 48.6% .0% 6.3 6.30.8 0.8 23712.0% 12.0% 4 2 1 47.8% 47.8% .0% 3.1 3.1 3838.9 3838.9 239 3.9%3.9% 4 4 1 35.8% 35.8% .0% 3.1 3.1 2010.5 2010.5 243 .6% .6% 0 0 1 31.9% 31.9% .0% 3.2 3.2 16.0 16.0 245 .6% .6% 1 0 1 31.3% 31.3% .0% 2.6 2.6 359.4359.4 247 7.0% .0% 4 5 1 30.7% 30.7% 30.7% 2.7 6.3 2910.4 0.0 251 3.8% 10.8% 11 2 0 23.7% 30.7% 30.7% 12.7 6.7 2013.0 4923.4 253 .1% .1% 0 0 0 19.9% 19.9% 19.9% 9.2 9.23.0 3.0 25410.5% 10.5% 13 1 0 19.8% 19.8% .0% 3.0 3.0 4974.4 4974.4 255 9.3%9.3% 8 0 0 9.3% 9.3% .0% 1.8 1.8 4215.4 4215.4 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edgington, Jerry Sent: Thursday, April 5, 2018 9:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WLM and Dispatching Priority SRM is a component of the system control program. It determines which address spaces, of all active address spaces, should be given access to system resources and the rate at which each address space is allowed to consume these resources. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edgington, Jerry Sent: Thursday, April 05, 2018 12:06 PM To: IBM-MAIN@LISTSERV.UA.EDU <mailto:IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: WLM and Dispatching Priority https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1 .ieaw200/iea3w201112.htm Dispatching Priority SRM defines dispatching priority for service class periods. All address spaces in a service class period have the same base dispatching priority. Multiple service class periods may have the same base dispatching priority. After a dispatching priority change, service class periods may be remapped to different dispatching priorities such that there is an unoccupied priority between each occupied priority. This process is referred to as priority unbunching. The dispatching priority is recorded in the subtype 2 records. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Thursday, April 05, 2018 12:02 PM To: IBM-MAIN@LISTSERV.UA.EDU <mailto:IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: WLM and Dispatching Priority I beg to diffe
Re: WLM and Dispatching Priority
I don't understand what you're trying to say. Enclaves are certainly assigned to service classes and can be reset or even quiesced. From the ENC display in SDSF NAMESSType StatusSrvClass Per 240002 STCINACTIVE SYSSTC 1 4C000C STCACTIVE SRVHIM 1 700015 STCINACTIVE SRVHIM 1 380007 STCACTIVE SRVHIM 1 48000B STCINACTIVE SRVHIM 1 5D STCACTIVE SRVHIM 1 680013 STCINACTIVE SRVHIM 1 340006 STCACTIVE SRVHIM 1 44000A STCINACTIVE SRVHIM 1 600011 STCACTIVE SRVHIM 1 640012 STCINACTIVE SRVHIM 1 49 STCACTIVE SRVHIM 1 58000F STCINACTIVE SRVHIM 1 5C0010 STCACTIVE SRVHIM 1 6C0014 STCINACTIVE SRVHIM 1 3C0008 STCACTIVE SRVHIM 1 54000E STCINACTIVE SRVHIM 1 I specifically don't understand what you mean by service classes not being applicable to server address spaces. How can any address space that is associated with a service class, not be managed to that service class' goals? It would have to be identifiable as a separate internal service class, but whatever the reason, it would have to be something that can be specifically seen and tracked using the Type 99 data. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, April 5, 2018 9:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WLM and Dispatching Priority On Thu, 5 Apr 2018 08:37:20 -0700, Gerhard Adam wrote: >I don't see the relevance of enclaves or anything else in this. It is >the service class period that matters. That is only one factor. Transaction response time goals are another factor. > >So, if I assigned DB2, enclaves, TSO, and batch to the same service >class, You don't assign an enclave to a service class. WLM defines enclaves based upon transaction response time goals and the address spaces that are involved in those transactions. Those server address spaces are managed to meet the goals of the transactions that include that address space in their enclave(s). This can get complicated because many different transactions with different requirements and involving different address spaces can be in different enclaves that involve an address space. WLM does not change the service class of those server address spaces, but it no longer manages them based on their service class. It wouldn't make any sense to change the service class of the DB2 region to match the service class of a CICS transaction whose enclave requires the DP of the DB2 region to change. At least, that's the way I understand it. >they should still all have the same dispatching priority. Workload >Manager doesn't care what type of work is in the service class, since >only the data related to the service class can be examined. That's not true of server address spaces. -- Tom Marchant -- 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: WLM and Dispatching Priority
Your documentation doesn't say what you say it does. It explicitly indicates that service class periods are associated with a dispatching priority and does not say anything about differences within a service class. In short, there is nothing to indicate that individual address spaces would be subject to variations in dispatching priorities within a service class period. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edgington, Jerry Sent: Thursday, April 5, 2018 9:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WLM and Dispatching Priority https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1 .ieaw200/iea3w201112.htm Dispatching Priority SRM defines dispatching priority for service class periods. All address spaces in a service class period have the same base dispatching priority. Multiple service class periods may have the same base dispatching priority. After a dispatching priority change, service class periods may be remapped to different dispatching priorities such that there is an unoccupied priority between each occupied priority. This process is referred to as priority unbunching. The dispatching priority is recorded in the subtype 2 records. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Thursday, April 05, 2018 12:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WLM and Dispatching Priority I beg to differ, but do you have documentation that supports what you say? I have looked at a lot of type 99 records and WLM most certainly assigns the DP. Sent from my iPhone > On Apr 5, 2018, at 8:44 AM, Edgington, Jerry wrote: > > WLM uses the configuration to determine what SRVCLASS a specific piece of work should be assigned upon initial job entry. After that, WLM will recommend to SRM how to adjust the dispatching priorities, based on information provided in WLM definitions. > > WLM doesn't make changes to dispatching priorities, only SRM does that. Also, SRVCLASS doesn't equal a specific dispatching priority. > > SRM still works like it always has and WLM is way of defining "business rules" to workload versus assigning specific dispatching priorities to the workload. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gerhard Adam > Sent: Thursday, April 05, 2018 11:37 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WLM and Dispatching Priority > > I don't see the relevance of enclaves or anything else in this. It is the service class period that matters. > > So, if I assigned DB2, enclaves, TSO, and batch to the same service class, they should still all have the same dispatching priority. Workload Manager doesn't care what type of work is in the service class, since only the data related to the service class can be examined. > > I would expect to see different dispatching priorities for the small consumer, or an address space that has been temporarily promoted, but that should only be short-term. I would also expect to see different dispatching priorities for the MTTW usage in discretionary. > > However, I still don't see how a goal-managed service class period can have different dispatching priorities. It would render the goal meaningless. > > Adam > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Martin Packer > Sent: Thursday, April 5, 2018 7:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WLM and Dispatching Priority > > There is also DIST and DBM1 in there. The action will be heavily > geared towards DBM1. (DIST has work in it mostly on Independent > Enclaves so relatively little of the work therein is at the address > space's DP.) > > Cheers, Martin > > Martin Packer > > zChampion, Systems Investigator & Performance Troubleshooter, IBM > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the mess
Re: WLM and Dispatching Priority
I beg to differ, but do you have documentation that supports what you say? I have looked at a lot of type 99 records and WLM most certainly assigns the DP. Sent from my iPhone > On Apr 5, 2018, at 8:44 AM, Edgington, Jerry > wrote: > > WLM uses the configuration to determine what SRVCLASS a specific piece of > work should be assigned upon initial job entry. After that, WLM will > recommend to SRM how to adjust the dispatching priorities, based on > information provided in WLM definitions. > > WLM doesn't make changes to dispatching priorities, only SRM does that. > Also, SRVCLASS doesn't equal a specific dispatching priority. > > SRM still works like it always has and WLM is way of defining "business > rules" to workload versus assigning specific dispatching priorities to the > workload. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gerhard Adam > Sent: Thursday, April 05, 2018 11:37 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WLM and Dispatching Priority > > I don't see the relevance of enclaves or anything else in this. It is the > service class period that matters. > > So, if I assigned DB2, enclaves, TSO, and batch to the same service class, > they should still all have the same dispatching priority. Workload Manager > doesn't care what type of work is in the service class, since only the data > related to the service class can be examined. > > I would expect to see different dispatching priorities for the small > consumer, or an address space that has been temporarily promoted, but that > should only be short-term. I would also expect to see different dispatching > priorities for the MTTW usage in discretionary. > > However, I still don't see how a goal-managed service class period can have > different dispatching priorities. It would render the goal meaningless. > > Adam > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Martin Packer > Sent: Thursday, April 5, 2018 7:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WLM and Dispatching Priority > > There is also DIST and DBM1 in there. The action will be heavily geared > towards DBM1. (DIST has work in it mostly on Independent Enclaves so > relatively little of the work therein is at the address space's DP.) > > Cheers, Martin > > Martin Packer > > zChampion, Systems Investigator & Performance Troubleshooter, IBM > > -- > 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
Re: WLM and Dispatching Priority
I don't see the relevance of enclaves or anything else in this. It is the service class period that matters. So, if I assigned DB2, enclaves, TSO, and batch to the same service class, they should still all have the same dispatching priority. Workload Manager doesn't care what type of work is in the service class, since only the data related to the service class can be examined. I would expect to see different dispatching priorities for the small consumer, or an address space that has been temporarily promoted, but that should only be short-term. I would also expect to see different dispatching priorities for the MTTW usage in discretionary. However, I still don't see how a goal-managed service class period can have different dispatching priorities. It would render the goal meaningless. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: Thursday, April 5, 2018 7:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WLM and Dispatching Priority There is also DIST and DBM1 in there. The action will be heavily geared towards DBM1. (DIST has work in it mostly on Independent Enclaves so relatively little of the work therein is at the address space's DP.) Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WLM and Dispatching Priority
While multiple periods certainly makes sense, the idea that different dispatching priorities exist within a single period service class doesn't. Workload manager adjusts the dispatching priority of an entire service class, both in terms of "unbunching" and in the algorithms used to assess the goals. To have individual units of work within a service class have different dispatching priorities renders any measurement meaningless. In other words, a service class could be meeting its goals simply because one unit of work has a higher priority while everything else suffers. Whether it is an enclave or an application's environment, presumably they would be classified into a unique service class in order to have a different dispatching priority. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: Thursday, April 5, 2018 6:34 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WLM and Dispatching Priority Correct. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gabriel Tully > Sent: 05 April, 2018 15:29 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WLM and Dispatching Priority > > These address spaces look like stored procedure address spaces and > they are likely marked as a server . Their goals would be managed > under the DDF subsystem in WLM classification rules and would depend > on what srvclasses are this ASID is servicing. > > Gabe > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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: WLM and Dispatching Priority
Workload manager doesn't manage individual address spaces within a service
class. That wouldn't make any sense.
That's why my question. After all, if the service class has varying
dispatching priorities, then how can the goal of the service class be assessed
when individual units of work have different goals?
Adam
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Thursday, April 5, 2018 6:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WLM and Dispatching Priority
Why shouldn't they? WLM manages Goals and uses all resources, including DPTRY,
to realize them.
I see this now:
Jobname SrvClass CUR
PTY
MZCMT01A BAT_PJ220
COECM01L BAT_PJ224
MZFFB03B BAT_PJ214
DBP1DBM1 DB2P_CTL 246
DBP1DIST DB2P_CTL 246
DB2PSPU1 DB2P_CTL 242
DB2PSPS2 DB2P_CTL 255
DBH1DBM1 DB2P_CTL 246
DBK1DIST DB2P_CTL 246
DBK1DBM1 DB2P_CTL 246
DBH1DIST DB2P_CTL 246
Kees.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gerhard Adam
> Sent: 05 April, 2018 13:23
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: WLM and Dispatching Priority
>
> Has anyone ever seen something like this before? Two started tasks
> {both
> DB2 address spaces] in the same service class and yet have different
> dispatching priorities? This screen capture shows the essential
> details.
>
> Any thoughts?
>
>
>
>
>
> Adam
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential and
privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to this
e-mail or attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately by return
e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission of
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered number
33014286
--
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: WLM and Dispatching Priority
Yes, sorry. For some reason the paste didn't work.
Basically it simply shows two tasks in the same service class with different
dispatching priorities. One has a priority of F6 and the other is F0.
Adam
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Elardus Engelbrecht
Sent: Thursday, April 5, 2018 5:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: WLM and Dispatching Priority
Gerhard Adam wrote:
>Has anyone ever seen something like this before? Two started tasks {both DB2
>address spaces] in the same service class and yet have different dispatching
>priorities? This screen capture shows the essential details.
What screen print? I only see white letters on a white background... ;-D
Perhaps you should re-post your question with more details using some
copy/paste actions?
Groete / Greetings
Elardus Engelbrecht
--
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: WLM and Dispatching Priority
Has anyone ever seen something like this before? Two started tasks {both
DB2 address spaces] in the same service class and yet have different
dispatching priorities? This screen capture shows the essential details.
Any thoughts?
Adam
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WLM and response time
Here's an example of why I'm questioning this. This is from a book by Robert Vaupel. I know he's knowledgeable, but the explanation is confusing. Using an average response time example he says "The running or in-flight transactions are also captured in order to make sure that long running and not ending transactions are used for managing the service class too.". Why should a transaction that hasn't ended be relevant? Sent from my iPhone > On Feb 15, 2018, at 10:34 AM, Allan Staller wrote: > > IIRC, WLM only uses ended transactions for the policy adjustment cycle. > > Further suggested reading SYSTEM Programmers Guide to WLM: > > www.redbooks.ibm.com/redbooks/pdfs/sg246472.pdf > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gerhard Adam > Sent: Thursday, February 15, 2018 11:25 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WLM and response time > > I agree. But the question remains. How does WLM manage a response time that > is longer than the policy adjustment interval? Is it only based on ended > transactions at that time (which would seem logical). > > I've also seen a lot of recommendations from various sources talking about > short batch, which is what gave rise to the question. Specifically the > recommendation used 5 initiators as the example. > > Also it doesn't matter if it is percentile or average response time. What > makes me wonder is that it basically tenders the percentile useless. > > For example, if I have an average response time of 1 sec, then it is easy to > see that enough transactions would end in an interval to provide samples to > evaluate. However let's also say that there are some transactions that will > experience a response time of 60 seconds (and stay in the same period). In > fact, this can happen with USS where transactions may show a response time of > 20 seconds. > > Since these end during different policy adjustment intervals, it seems that > they are only a sporadic effect, because during the interval when none end, > the average response time would hold. During the intervals when they do end, > the percentile would be applicable. > > Yet wouldn't this cause me to perpetually fluctuate between exceeding goals > and meeting them? After all during the intervals when I have no long running > transactions ending, I would show 100% meeting goals and exceed by goal. > > Yet I don't recall ever seeing this kind of behavior. > > Sent from my iPhone > >> On Feb 15, 2018, at 6:17 AM, Allan Staller wrote: >> >> Response time goals for batch do not (IMO) make any sense. >> >> WLM is predicated on having enough samples to make an informed decision. If >> you only have 1 or 2 samples (ended transactions) in an interval, that is >> not statistically valid. >> I would suggest a velocity goal be used in its place. >> >> If queue time is needed to be considered, the I would expand the suggestion >> to include WLM managed initiators. This will change the velocity calculation >> to include queue time as part of the delay. >> >> Suggested reading: >> ftp://public.dhe.ibm.com/s390/zos/wlm/WLMvelocity.pdf >> >> HTH, >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Gerhard Adam >> Sent: Wednesday, February 14, 2018 9:40 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: WLM and response time >> >> Well, this may seem like an obvious answer, but I can't tell if I'm >> confusing myself or missing something. >> >> If I use a long response time (like 10 minutes for batch), then I would >> think that I only consider that during the Performance Adjustment interval >> in which the transaction ends. Yet that raises the question that if I have >> multiple jobs in such a service class, then over what interval must they end >> to provide a meaningful metric? Assuming they would all end within a 10 >> second window seems implausible, so how can a response time goal >> realistically be managed at such high values? >> >> In addition I recently read that even transactions that haven't ended can be >> used in the evaluation of goals, but that doesn't make sense since, by >> definition, they haven't ended. Yet this is what percentile goals are >> supposed to represent. >> >> So
Re: WLM and response time
I agree. But the question remains. How does WLM manage a response time that is longer than the policy adjustment interval? Is it only based on ended transactions at that time (which would seem logical). I've also seen a lot of recommendations from various sources talking about short batch, which is what gave rise to the question. Specifically the recommendation used 5 initiators as the example. Also it doesn't matter if it is percentile or average response time. What makes me wonder is that it basically tenders the percentile useless. For example, if I have an average response time of 1 sec, then it is easy to see that enough transactions would end in an interval to provide samples to evaluate. However let's also say that there are some transactions that will experience a response time of 60 seconds (and stay in the same period). In fact, this can happen with USS where transactions may show a response time of 20 seconds. Since these end during different policy adjustment intervals, it seems that they are only a sporadic effect, because during the interval when none end, the average response time would hold. During the intervals when they do end, the percentile would be applicable. Yet wouldn't this cause me to perpetually fluctuate between exceeding goals and meeting them? After all during the intervals when I have no long running transactions ending, I would show 100% meeting goals and exceed by goal. Yet I don't recall ever seeing this kind of behavior. Sent from my iPhone > On Feb 15, 2018, at 6:17 AM, Allan Staller wrote: > > Response time goals for batch do not (IMO) make any sense. > > WLM is predicated on having enough samples to make an informed decision. If > you only have 1 or 2 samples (ended transactions) in an interval, that is not > statistically valid. > I would suggest a velocity goal be used in its place. > > If queue time is needed to be considered, the I would expand the suggestion > to include WLM managed initiators. This will change the velocity calculation > to include queue time as part of the delay. > > Suggested reading: ftp://public.dhe.ibm.com/s390/zos/wlm/WLMvelocity.pdf > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gerhard Adam > Sent: Wednesday, February 14, 2018 9:40 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WLM and response time > > Well, this may seem like an obvious answer, but I can't tell if I'm confusing > myself or missing something. > > If I use a long response time (like 10 minutes for batch), then I would think > that I only consider that during the Performance Adjustment interval in which > the transaction ends. Yet that raises the question that if I have multiple > jobs in such a service class, then over what interval must they end to > provide a meaningful metric? Assuming they would all end within a 10 second > window seems implausible, so how can a response time goal realistically be > managed at such high values? > > In addition I recently read that even transactions that haven't ended can be > used in the evaluation of goals, but that doesn't make sense since, by > definition, they haven't ended. Yet this is what percentile goals are > supposed to represent. > > So I guess my question involves how a policy adjustment interval addresses > transaction that run longer than the time between intervals, or is it merely > that they are only examined during the interval they actually end in? > > Adam > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > -- > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses > in transmission. The e mail and its contents (with or without referred > errors) shall therefore not attach any liability on the originator or HCL or > its affiliates. Views or opinions, if any, presented in this email are solely > those of the author and may not necessarily reflect the views or opinions of > HCL or its affiliates. Any form of reproduction, dissemination, copying, >
Re: WLM and response time
For additional clarification, consider a batch response time goal of 10 minutes. If we assume 5 initiators, and the service class is managed by transaction class for these 5 initiators, then how do I not risk have a policy adjustment interval where there is only one response time sample in any of the buckets during the adjustment interval. It would render the percentile response time worthless. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: WLM and response time
Well, this may seem like an obvious answer, but I can't tell if I'm confusing myself or missing something. If I use a long response time (like 10 minutes for batch), then I would think that I only consider that during the Performance Adjustment interval in which the transaction ends. Yet that raises the question that if I have multiple jobs in such a service class, then over what interval must they end to provide a meaningful metric? Assuming they would all end within a 10 second window seems implausible, so how can a response time goal realistically be managed at such high values? In addition I recently read that even transactions that haven't ended can be used in the evaluation of goals, but that doesn't make sense since, by definition, they haven't ended. Yet this is what percentile goals are supposed to represent. So I guess my question involves how a policy adjustment interval addresses transaction that run longer than the time between intervals, or is it merely that they are only examined during the interval they actually end in? Adam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help with JES2 Offloader
It might be appropriate to have a REXX/SDSF routine that can select the work you are interested in, and perhaps set a unique DESTID to differentiate it from other work. After that, the OFFLOAD is straightforward. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Sunday, February 4, 2018 12:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Help with JES2 Offloader List - I have not setup an offloader in a few decades. I am not sure if I can do what I want I know how to setup the Offloader, the OFFx.Sx and dataset name/retention/unit I have a JES2 Output queue, call it OUTPUT CLASS A, where I need to offload some but not all of the output I would like to offload all work from Jan 2018 in output class A and nothing else. These have various jes2 jobnums, writer names, owner names, etc. So there is no criteria that would be very specific to what I want. What I would like to do is offload the OUTPUT CLASS A output by jobname mask AND create-date CRDATE Is that possible? Or would there be another process? It must be with the JES2 Offloader - no 3rd party products can be used or acquired. I have been reading the manuals, but I am not finding much on the crdate I would like to use. I did see that I might need to look at $WSTAB as a way to get CRDATE, but I have not explored that yet. Thanks Lizette Koehler statistics: A precise and logical method for stating a half-truth inaccurately A theory can never be proven, but it can be falsified. Karl Raimund Popper -- 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: Problem with JCL
Why not simply make Part B and Part C, separate jobs and use IEBGENER to submit
them to the internal reader based on condition code? If they can't reside in
a PDS, then make them instream data to be passed to the IEBGENER based on
return code.
Adam
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Elardus Engelbrecht
Sent: Wednesday, January 31, 2018 5:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Problem with JCL
Ward Able, Grant wrote:
>I have a situation where I need to execute a single JCL procedure, but ONLY
>execute some steps (including the DSN allocations) for part B or part C,
>depending on the return code of part A. The problem I seem to be stuck with is
>that in part B (STEP10 below) I have some datasets defined in the JCL with
>UNIT=SYSDA and VOL=SER=XX. However, if STEPA.RC is not 12, then we are not
>executing in an environment where VOL=SER=XX is available/mounted. I have
>been told that I need to have this whole job as a single unit, so it can
>execute in the different environments as necessary.
Ouch that is a hard ugly one.
Split up your jobs in separate jobs or try dynamic, but conditional allocations?
Or insert steps to check for dsn, like this Clist example in a IKJEFT step:
PROC 0
IF &SYSDSN('???.JCL') = OK THEN +
DO
WRITE DATASET FOUND
SET &RC = 0
END
ELSE +
DO
WRITE DATA SET NOT FOUND
SET &RC = 4
END
Use that RC to do your IF checking...
>Is this feasible? Can it be achieved,
Perhaps if there is a way to check the status of a VOLSER in a batch job.
Good luck. If I were you, I had given that assignment to some young
programmer... ;-)
Groete / Greetings
Elardus Engelbrecht
--
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: Problem with JCL
Sorry, but how is this not just a standard condition code test? Sent from my iPhone > On Jan 31, 2018, at 4:45 AM, Jantje. wrote: > >> On Tue, 30 Jan 2018 15:36:29 +, Ward Able, Grant >> wrote: >> >> I have a situation where I need to execute a single JCL procedure, but ONLY >> execute some steps (including the DSN allocations) for part B or part C, >> depending on the return code of part A. > > May I suggest you use dynamic allocation for that? I don't think there is any > other way of achieving your requirement. > > Cheers, > > Jantje. > > -- > 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: SYSOUT not accumulated
While I don't know what product you're referring to, but clearly there can be no problem with JES if you have output in class D Sent from my iPhone > On Jan 29, 2018, at 8:26 PM, Peter wrote: > > Hello > > We have updated the output class D in our JES output reporting tool. Still > we don't see the product accumulating the Job submitted with the class D. > We can see the SYSOUT is getting some 50k lines of output. > > There is no error from the product side. > > Syslog doesn't give any clue too. Is there any other prerequisite to be > checked from JES point of view ? > > Regards > 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: VSAM Performance - CPU reduction
To me it still looks like you don't have enough index buffers. My calculation suggests you need at least 137 buffers to keep the index set in memory. Sent from my iPhone > On Jan 7, 2018, at 10:21 AM, Arun Venkatratnam > wrote: > > Ron, > > About 80% of the records qualify from the second file. I tried running the > job with BUFND of 2 for the second file. It increased the EXCPs significantly > (from strobe report) on the data records for the 2nd file and the CPU time > went over the other runs and the elapsed time also increased. The job runs > better with higher values of BUFND for the second file. > > You had mentioned that the job reads 30 CI for every skip-seq access. Could > you please tell how did you arrive at that number. LISTCAT shows that for a > CISZ of 26KB, there are 30 CI in 1 CA. > > > Thanks > Arun > > -- > 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: VSAM Performance - CPU reduction
Seems a bit round-about. Why not REPRO them to a sequential file, sort by key, and then produce your output. Sent from my iPhone > On Jan 5, 2018, at 4:20 PM, Arun Venkatratnam > wrote: > > Hi All, > > We are looking to improve the performance of a COBOL program that processes 2 > VSAM files. The first file is the I/P file and every record read from the > input VSAM file is searched for a matching record in the other file and a > report is written. The program also applies some business rules while > comparing each matching record. > > The I/P file is read sequentially while the other file is read in a skip > sequential basis. The test files that were used had 32M records each while > production files have 110M records each. > > Attached is the strobe report from the execution of the test job. The test > job takes nearly 7 CPU minutes and was profiled to capture about 1 CPU minute > of execution time. > > We are attempting to optimize the VSAM access to these files as it is seen to > take more than 50% of the CPU consumed by this job. > > In the 'Attribution of CPU execution time' section, we see that the major > contributors are the components 'QSAM INIT I/O & EXITS' (Module IGZEQBL) and > PARTITION COMMUNICATION. > > Could you please help us understand: > > 1.What these components are > 2.Why is QSAM access used instead of VSAM I/O access. > 3.What needs to be done to reduce the CPU consumption by these components. > > Thank you > > Arun > > > -- > > 1Strobe* PERFORMANCE PROFILE PROGRAMA > 01/02/2018 PAGE 42 > > - #ACE ** ATTRIBUTION OF CPU EXECUTION > TIME ** > -.COBLIB IGZCPCO IGZEVIO VSAM INPUT/OUTPUT > > ---WAS INVOKED BY- > -VIA--- CPU TIME % > XACTION MODULE SECTION DESCRIPTION MODULE > SECTION DESCRIPTION SOLO TOTAL > > .LELIB CEEBINIT LE/370 BATCH INIT/TERM >.32 .32 > .LELIB CEEBINIT LE/370 BATCH INIT/TERMIGZEQBL > QSAM INIT I/O & EXITS1.93 1.93 > > XACTION MODULE SECTION LOCATION LINE SOURCE TEXT MODULE > SECTION DESCRIPTION > > PROGRAMA PROGRAMA 003522 > 1.30 1.30 > > >- - > > >3.55 3.55 > -.VSAMIDA019L1 VSAM RECORD MANAGEMENT > > ---WAS INVOKED BY- > -VIA---CPU TIME % > XACTION MODULE SECTION DESCRIPTION MODULE > SECTION DESCRIPTION SOLO TOTAL > > .LELIB CEEBINIT LE/370 BATCH INIT/TERMIGZEQBL > QSAM INIT I/O & EXITS 1.84 1.84 > .LELIB CEEBINIT LE/370 BATCH INIT/TERMIGZEQBL > CURRMEM QSAM INIT I/O & EXITS 4.34 4.38 > .LELIB CEEBINIT LE/370 BATCH INIT/TERMIGZEQBL > DVFILE QSAM INIT I/O & EXITS.03 .03 > .LELIB CEEBINIT LE/370 BATCH INIT/TERMIGZEQBL > PREVMEM QSAM INIT I/O & EXITS 22.48 22.51 > > XACTION MODULE SECTION LOCATION LINE SOURCE TEXT MODULE > SECTION DESCRIPTION > > PROGRAMA PROGRAMA 003522 IGZCPCO > CURRMEM PARTITION COMMUNICATION4.15 4.19 > PROGRAMA PROGRAMA 003522 IGZCPCO > IGZEVIO VSAM INPUT/OUTPUT .57 .57 > PROGRAMA PROGRAMA 003522 IGZCPCO > PREVMEM PARTITION COMMUNICATION 16.80 16.80 > > > - - > >
Re: How to find the Global zone names in SMP/E via REXX
Isn't that the point of getting a file allocation report with every SMP run? Adam Sent from my iPhone On Aug 9, 2017, at 7:58 PM, Edward Gould wrote: >> On Aug 9, 2017, at 4:34 PM, Paul Gilmartin >> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: >> >>> On Wed, 9 Aug 2017 20:58:11 +0100, CM Poncelet wrote: >>> ——SNIP-- >> If the DSNames are in DDDEFs (highly recommended) they can be listed >> with SMP/E commands. At times, a question has been posed here, >> "Can I, for a one-off, overide in JCL the DDDEFs in the CSIs?" Yes, but >> don't do that! > > Gil, > > I have a preference to use JCL with dd’s in the step(proc) for maintenance. > > I have been burned by a fellow sysprog as he managed to put the maintenance > in the wrong zone. > > After the IPL I started to get the phone calls saying that X is still broken. > The time it takes is a PITA. I then have to track down what went where. > I also get a black mark from the programmers and my boss for screwing it up. > The black mark from the programmers is aggravating as then they stop trusting > me and I have to earn their trust back. The boss is not so forgiving even > when a 3rd person is involved. His answer is your fault as you didn’t verify > what the person did. Personally I don’t have the time in the day/evening to > check out what fellow sysprogs did. About 20 years ago I was putting in 100 > hour work weeks and it burned me out. > Once I figure out what happened, that means paper work and another scheduled > IPL. > I can *TRUST* JCL and not worry about the DDEF’s which are for all intents > purposes is invisible. > > Ed > -- > 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: JES2 Checkpoint question
I disagree. The point of reconfiguration is also to recover from checkpoint loss. Sent from my iPhone > On Jul 31, 2017, at 3:00 AM, Vernooij, Kees (ITOPT1) - KLM > wrote: > > But still, if both checkpoints were in CF's, the POR cleared both of them, so > there is nothing to reconfigure. A COLD start would indeed be the fastest. > > Kees. > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Gerhard Adam >> Sent: 28 July, 2017 18:17 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: JES2 Checkpoint question >> >> I wasn't sure if you were aware that you can make up a NEWCKPT >> dynamically and if it doesn't exist, JES2 will prompt you to create it. >> >> That way if you don't have an existing definition, you can still get a >> new data set created and migrated to. >> >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Carmen Vitullo >> Sent: Friday, July 28, 2017 7:15 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: JES2 Checkpoint question >> >> thank you >> I decided to do a cold start due to the fact while an attempt to move to >> NEWCKPRT1 or 2 during startup I received I/O errors on the CKPT files, >> due to time constrains on my downtime I had to get the systems back up. >> I've since read there are somethings I could have tried to recover, but >> at the timethere was no time. >> >> >> Carmen >> >> - Original Message - >> >> From: "Gerhard Adam" >> To: IBM-MAIN@LISTSERV.UA.EDU >> Sent: Friday, July 28, 2017 9:08:21 AM >> Subject: Re: JES2 Checkpoint question >> >> You shouldn't need both on DASD. However, I am curious as to why you had >> to COLD start. >> >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Carmen Vitullo >> Sent: Friday, July 28, 2017 6:55 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: JES2 Checkpoint question >> >> I've looked and looked at the Init and Tuning REF and Guide and I can't >> seem to find an answer to my question, I'm hoping someone can provide a >> sanity check for me. >> I have a 2 system JES2 MAS both running z/OS 2.1, both checkpoints are >> currently in a CF with mode=duplex and duplex=on. >> my issue is both CF's are in the same CEC so a POR of the box for maint >> last month I lost all my prod spool data and was forced to perform a >> JES2 cold start. I need to move CKPT1 to DASD and I want to leave CKPT2 >> in the CF, so my question is can I still run with mode=duplex and >> duplex=on in that configuration, or do I need to have both CKPT's on >> DASD. >> Any insight or recommendations would be very helpful, thank you all >> >> -- >> 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 >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain confidential > and privileged material intended for the addressee only. If you are not the > addressee, you are notified that no part of the e-mail or any attachment may > be disclosed, copied or distributed, and that any other action related to > this e-mail or attachment is strictly prohibited, and may be unlawful. If you > have received this e-mail by error, please notify the sender immediately by > return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
Re: JES2 Checkpoint question
I wasn't sure if you were aware that you can make up a NEWCKPT dynamically and if it doesn't exist, JES2 will prompt you to create it. That way if you don't have an existing definition, you can still get a new data set created and migrated to. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Friday, July 28, 2017 7:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: JES2 Checkpoint question thank you I decided to do a cold start due to the fact while an attempt to move to NEWCKPRT1 or 2 during startup I received I/O errors on the CKPT files, due to time constrains on my downtime I had to get the systems back up. I've since read there are somethings I could have tried to recover, but at the timethere was no time. Carmen - Original Message ----- From: "Gerhard Adam" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, July 28, 2017 9:08:21 AM Subject: Re: JES2 Checkpoint question You shouldn't need both on DASD. However, I am curious as to why you had to COLD start. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Friday, July 28, 2017 6:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES2 Checkpoint question I've looked and looked at the Init and Tuning REF and Guide and I can't seem to find an answer to my question, I'm hoping someone can provide a sanity check for me. I have a 2 system JES2 MAS both running z/OS 2.1, both checkpoints are currently in a CF with mode=duplex and duplex=on. my issue is both CF's are in the same CEC so a POR of the box for maint last month I lost all my prod spool data and was forced to perform a JES2 cold start. I need to move CKPT1 to DASD and I want to leave CKPT2 in the CF, so my question is can I still run with mode=duplex and duplex=on in that configuration, or do I need to have both CKPT's on DASD. Any insight or recommendations would be very helpful, thank you all -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Checkpoint question
You shouldn't need both on DASD. However, I am curious as to why you had to COLD start. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Friday, July 28, 2017 6:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES2 Checkpoint question I've looked and looked at the Init and Tuning REF and Guide and I can't seem to find an answer to my question, I'm hoping someone can provide a sanity check for me. I have a 2 system JES2 MAS both running z/OS 2.1, both checkpoints are currently in a CF with mode=duplex and duplex=on. my issue is both CF's are in the same CEC so a POR of the box for maint last month I lost all my prod spool data and was forced to perform a JES2 cold start. I need to move CKPT1 to DASD and I want to leave CKPT2 in the CF, so my question is can I still run with mode=duplex and duplex=on in that configuration, or do I need to have both CKPT's on DASD. Any insight or recommendations would be very helpful, thank you all -- 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: REGION=0M leads to CPU through the roof
I don't see paging as the culprit. To page out 1.6 GB of memory and then reference it to bring it back in still indicates an application problem. Especially with a total elapsed time of only 12 minutes. I suspect that the application built a table. Spent wasted time searching it. Sent from my iPhone > On Jul 27, 2017, at 6:50 PM, Ron Hawkins wrote: > > Charles, > > YES I AGREE, storage nowadays can do a lot of paging, and support a CEC > easily burning 11 minutes of CPU time paging. DPR rates of 100,000/sec are a > walk in the park for current IBM, EMC or HDs controllers, and probably > higher on a boxes that can do >2,000,000 cache hits a second. > > Of course, if the OP is not actually going to look at anything but the CPU > time, he will probably never find out what cause it. > > Ron > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Charles Mills > Sent: Wednesday, July 26, 2017 5:37 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] REGION=0M leads to CPU through the roof > > By ELEVEN CPU MINUTES??? > > A modern processor can do a heck of a lot of paging with 11 CPU minutes. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ron Hawkins > Sent: Wednesday, July 26, 2017 5:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: REGION=0M leads to CPU through the roof > > Richard, > > You used 1.6GB of virtual storage. > > How much paging did the address do? There's no free lunch, and page faults > will increase the TCB time for an address. > > -- > 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
Re: REGION=0M leads to CPU through the roof
What's strange to me, is that the program used up all the available storage indicated by coding REGION=0M. This clearly means that the program is dynamically adjusting the amount of storage that it needs based on the available region. After all, if it were of fixed size, then coding 0M wouldn't have any effect on what was going used. Since the amount of storage was nearly 50 times greater than the original, it seems that the program is clearly managing [or searching] are large amount of storage that it doesn't need. It seems that that might account for the CPU time increase. I see no reason why a program that successfully ran using the default region, should suddenly allocate all the available memory just because 0M was coded. Even though you said the increase in storage was not surprising, it actually is. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Kielstra Sent: Monday, July 24, 2017 3:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REGION=0M leads to CPU through the roof Do you have access to Application Performance Analyzer (APA) or Strobe (or FreezeFrame)? If not, can you cut the program down to some kernel that exhibits the same characteristic? Also, do you happen to have COBOL V5 or V6 (maybe the trial version)? -- 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: REGION=0M leads to CPU through the roof
OK, so no useful work was performed in the extra time. The longer elapsed time correlated with the increase in CPU time, which suggests a loop of some type, that burns up cycles but contributes nothing to getting the work done. Just guessing here. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Way, Richard Sent: Monday, July 24, 2017 3:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REGION=0M leads to CPU through the roof Oh, the elapsed time absolutely changed in a very noticeable way, of course. 12.55 minutes with REGION=0M, 0.60 minutes without any REGION specified. This is (more-or-less) repeatable at will. But the work being done (number of records read, processed, written, and the nature of the processing) was identical in both cases. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Monday, July 24, 2017 3:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REGION=0M leads to CPU through the roof How much did the elapsed time change? I find it hard to believe that the job actually ran 22 x longer and that wasn't notable as a difference. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Way, Richard Sent: Monday, July 24, 2017 2:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REGION=0M leads to CPU through the roof Thanks! I'm a little reluctant to run a job that already takes 12 CPU-minutes with RPTSTG(ON), but I may be able to cut the test data back significantly and still see the relative increase, in which case this may be very useful. I'll read through that tuning document as well! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Monday, July 24, 2017 2:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REGION=0M leads to CPU through the roof Running both with RPTSTG(ON) may provide insight. See also: http://www-01.ibm.com/support/docview.wss?uid=swg27018287&aid=1 Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Jul 24, 2017 at 4:32 PM, Way, Richard wrote: > Same result, same return code - yes. Customer found that one release of > our product got an 878 when a prior release had not. I was > experimenting to see if I could drive the 878 by finding the point > (REGION=) at which the 878 first occurs in the two releases of our > product (to see if it was just "normal" additional memory needs or > something more sinister). As it turned out, I got this other behavior > (wild CPU consumption) in the course of experimentation. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Allan Kielstra > Sent: Monday, July 24, 2017 2:27 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: REGION=0M leads to CPU through the roof > > I want to be clear on one thingThe program produces the same > result and has the same return code in both cases? Possibly another > way of asking the same thing is: why did you alter the region size in the > first place? > > -- > 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 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REGION=0M leads to CPU through the roof
How much did the elapsed time change? I find it hard to believe that the job actually ran 22 x longer and that wasn't notable as a difference. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Way, Richard Sent: Monday, July 24, 2017 2:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REGION=0M leads to CPU through the roof Thanks! I'm a little reluctant to run a job that already takes 12 CPU-minutes with RPTSTG(ON), but I may be able to cut the test data back significantly and still see the relative increase, in which case this may be very useful. I'll read through that tuning document as well! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Monday, July 24, 2017 2:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REGION=0M leads to CPU through the roof Running both with RPTSTG(ON) may provide insight. See also: http://www-01.ibm.com/support/docview.wss?uid=swg27018287&aid=1 Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Jul 24, 2017 at 4:32 PM, Way, Richard wrote: > Same result, same return code - yes. Customer found that one release of > our product got an 878 when a prior release had not. I was > experimenting to see if I could drive the 878 by finding the point > (REGION=) at which the 878 first occurs in the two releases of our > product (to see if it was just "normal" additional memory needs or > something more sinister). As it turned out, I got this other behavior > (wild CPU consumption) in the course of experimentation. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Allan Kielstra > Sent: Monday, July 24, 2017 2:27 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: REGION=0M leads to CPU through the roof > > I want to be clear on one thingThe program produces the same > result and has the same return code in both cases? Possibly another > way of asking the same thing is: why did you alter the region size in the > first place? > > -- > 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 -- 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-calling-Asembler and 24bit mode
Never mind, just noticed that that point had already been made. Sent from my iPhone > On May 20, 2017, at 12:54 PM, Charles Mills wrote: > > Is my understanding correct? > > - the call from COBOL to assembler is dynamic; that is, the assembler > programs are separately linkedited AMODE/RMODE 24. > - the assembler programs contain hard-coded DCB, OPEN, GET/PUT, etc. > > If so, yes, if you call from COBOL to assembler the I/O should all work. > > If you pass parms from COBOL to assembler you are going to have a problem in > that the data may be above the bar, and the assembler program has no way of > addressing it. Ditto for any save area, for that matter. You need to code and > link the assembler programs RMODE 24/AMODE 31. > > An alternative approach is to make the assembler code all 31-bit but do a > GETMAIN for 24-bit storage and copy the DCB into that storage and OPEN it > there. A little more to it than that; follow up if interested in this > approach. Has the advantage of facilitating reentrance. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of scott Ford > Sent: Saturday, May 20, 2017 11:25 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Cobol-calling-Asembler and 24bit mode > > ALL: > > I have a STC in Cobol running with these compile options: > > CBL NOC(E),FLAG(W),DATA(31),NODYN,RES,RENT,MAP,SSR > CBL NOZWB,NUM,NOTERM,NOVBREF,X,APOST,LIB,LIST > > we link as : > > MODE AMODE(31),RMODE(ANY) > > So my question is we call assembler programs using I/O to QSAM with > ADMODE(24) and RMODE(24), is my assumption correct that the I/O and buffers > of the called assembler routine will be below the 16m line ? If so is there a > way , I know you can re-alloc the DCB buffers above the line but part of the > DCB definitions must be below the line. > > I have a copy of the Share presentation on Trimodal Programming by the great > John Ehrman. I could a routine or process like he shows. My issue is the > amount of data...30 x 80bytes ... > > All comments are helpful and appreciated. > > Regards, > > *IDMWORKS* > > Scott Ford > > z/OS Dev. > > > > > “By elevating a friend or Collegue you elevate yourself, by demeaning a > friend or collegue you demean yourself” > > > > www.idmworks.com > > scott.f...@idmworks.com > > Blog: www.idmworks.com/blog > > > > > > > *The information contained in this email message and any attachment may be > privileged, confidential, proprietary or otherwise protected from disclosure. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, distribution, copying or use of this message > and any attachment is strictly prohibited. If you have received this message > in error, please notify us immediately by replying to the message and > permanently delete it from your computer and destroy any printout thereof.* > > -- > 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
Re: Cobol-calling-Asembler and 24bit mode
Why not simply make the program AMODE 31 and RMODE 24? Sent from my iPhone > On May 20, 2017, at 12:54 PM, Charles Mills wrote: > > Is my understanding correct? > > - the call from COBOL to assembler is dynamic; that is, the assembler > programs are separately linkedited AMODE/RMODE 24. > - the assembler programs contain hard-coded DCB, OPEN, GET/PUT, etc. > > If so, yes, if you call from COBOL to assembler the I/O should all work. > > If you pass parms from COBOL to assembler you are going to have a problem in > that the data may be above the bar, and the assembler program has no way of > addressing it. Ditto for any save area, for that matter. You need to code and > link the assembler programs RMODE 24/AMODE 31. > > An alternative approach is to make the assembler code all 31-bit but do a > GETMAIN for 24-bit storage and copy the DCB into that storage and OPEN it > there. A little more to it than that; follow up if interested in this > approach. Has the advantage of facilitating reentrance. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of scott Ford > Sent: Saturday, May 20, 2017 11:25 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Cobol-calling-Asembler and 24bit mode > > ALL: > > I have a STC in Cobol running with these compile options: > > CBL NOC(E),FLAG(W),DATA(31),NODYN,RES,RENT,MAP,SSR > CBL NOZWB,NUM,NOTERM,NOVBREF,X,APOST,LIB,LIST > > we link as : > > MODE AMODE(31),RMODE(ANY) > > So my question is we call assembler programs using I/O to QSAM with > ADMODE(24) and RMODE(24), is my assumption correct that the I/O and buffers > of the called assembler routine will be below the 16m line ? If so is there a > way , I know you can re-alloc the DCB buffers above the line but part of the > DCB definitions must be below the line. > > I have a copy of the Share presentation on Trimodal Programming by the great > John Ehrman. I could a routine or process like he shows. My issue is the > amount of data...30 x 80bytes ... > > All comments are helpful and appreciated. > > Regards, > > *IDMWORKS* > > Scott Ford > > z/OS Dev. > > > > > “By elevating a friend or Collegue you elevate yourself, by demeaning a > friend or collegue you demean yourself” > > > > www.idmworks.com > > scott.f...@idmworks.com > > Blog: www.idmworks.com/blog > > > > > > > *The information contained in this email message and any attachment may be > privileged, confidential, proprietary or otherwise protected from disclosure. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, distribution, copying or use of this message > and any attachment is strictly prohibited. If you have received this message > in error, please notify us immediately by replying to the message and > permanently delete it from your computer and destroy any printout thereof.* > > -- > 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
Re: SDB (system determined Blksize)
I don't see how the space would not be wasted. Where would it be assigned or accounted for? If you ignored such waste, you could have more capacity available than the volumes you've defined. Sent from my iPhone On May 20, 2017, at 10:40 AM, Charles Mills wrote: >> if you write a 32K block to an emulated 3390 track, the balance of the > space will be wasted > > Is that true? (Serious question -- everything I know about DASD management > could be written in one paragraph of an e-mail.) Sure, it wastes "virtual" > space on the emulated 3390 track, no doubt, but aren't modern storage arrays > smart enough not to waste the real disk space that you are paying for on > empty 3390 track space? > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ron Hawkins > Sent: Friday, May 19, 2017 4:47 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SDB (system determined Blksize) > > Lizette (OP), > > > > I would not recommend going to 32K as a blocking factor. Generically > speaking, all three vendor emulate a CKD track, allocating up to 64KiB of > space for every track. > > > > Whether you use a regular formatted volume, or thin provisioning (DP-VOL in > Hitachi speak), if you write a 32K block to an emulated 3390 track, the > balance of the space will be wasted. Ipso fact you will use 41% more space > for the same amount of data at half-track. > > -- > 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: SDB (system determined Blksize)
>I'm skeptical that layer(s) of emulation incur no performance penalty. >Wouldn't a hypothetical emulated device supporting two 32760-byte blocks per >track, or one 65535-byte block (the CCW count field) >do better? What files would benefit? Other than sequential files, what files will benefit by a larger blocksize versus simply leaving things as they are and using more buffers? Bear in mind that such a change as you're proposing would also require that every file be redefined, copied, and all accompanying JCL changed for space/blocksize considerations. After all that work, what actual improvement would one expect to see? I don't see anything that warrants much excitement for the effort involved. Adam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDB (system determined Blksize)
z/OS doesn't emulate 3390's, the disk technology does. It also does so, for good reason, because the biggest issue with DASD is differing geometries. That would affect space allocation and the blocksizes that can be used. Since there is no performance penalty for emulating a 3390, there is zero incentive for anyone to represent their disks as anything except a 3390. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Steve Smith Sent: Friday, May 19, 2017 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDB (system determined Blksize) Considering the many layers of emulation and fakery between application and actual recorded media these days, I highly doubt these considerations matter much at all. While it makes sense to maximize BLKSIZE, that's a low-order optimization, only worth doing because it's free. It's rather a shame z/OS is still stuck with emulating a very obsolete disk technology. sas On Fri, May 19, 2017 at 5:21 PM, Jesse 1 Robinson wrote: > SDB was invented to automatically optimize two competing efficiencies: > I/O overhead and physical disk storage. To wit, the fewer I/Os the > better; and the less wasted track space the better. > > For I/O, the ideal operation is reading or writing an entire 'data > component' in one operation. For disk storage, the ideal is to occupy > every available bit on a track. > > To maximize track occupancy, one logical record per block probably > achieves maximum efficiency but is horrible in the I/O arena. For I/O > efficiency, a largest possible block that occupies that fits on a > track achieves the fewest I/Os but may result in egregious wasted space. > > For exceptional cases, you can override SDB by coding explicit > blocksizes, but that seems like a lot of work. Setting out to supplant > the IBM provided SBD algorithms with 'something smarter' seems like > even more work with questionable ROI. > > BTW I have no idea how to answer your actual question. Relying on my > college survival strategy, I'm trying to supply an interesting and > maybe even useful answer to a different question. ;-) > > . > . > 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 Allan Staller > Sent: Friday, May 19, 2017 11:59 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: SDB (system determined Blksize) > > IBM for many years supplied a macro or subroutine called TRKCALC that > can be used for space calculations. I don't know if it's still around. GIYF. > > The actual formula used is: > > Physical records per track = 1729/(10+K+D) > > D= 9 + (DATALEN + (6x((DATALEN+6/232)) +6/) /34 > > K = 0 if non-keyed > K= 9 + (keylen + ( 6* ((keylen+6/232)) + 6) /34 (if keyed) > > > > 1) I would imagine it can , but I am baffled as to where it would be > specified. The most likely options are in the CDS, or IGDSMSxx. > 2) See # 3. > 3) SLED devices generated the recommendation for 1/2 track blocking > for the following reasons: > a) Maximizing the use of space. > b) Minimizing physical IO to the device . > > With the advent of RAID devices, the physical IO portion has much less > importance. There might be some performance IOS related overhead due > to increase number of IO requests With the reduction in DASD prices, > does the percentage of utilization matter as much as it used to > > I have not heard of any research in this area? Is Pat Artis still > active, or has he retired? > > HTH, > > > > I have gone through a few manuals and cannot determine the answer to > the following questions. Any guidance is appreciated > >1) Can the SDB be adjusted from half-track to another setting > (quarter or full)? >2) Are there any new best practices for SDB that have changed in > the last 20 years? >3) Is Half-track still considered OPTIMUM? > > Since the storage arrays are so fast, I would think that maybe full > track would not be that much of a performance impact any more. > > I have been working offlist with a couple of people with JCL and > BLKSIZE and SPACE Sizing. I am trying to figure out how to make the > formula more accurate. > When I calculate space - I use full trace blocking. However, I find > when SDB uses half-track, my math is off. > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDB (system determined Blksize)
I'm not sure why you think these are competing efficiencies. A large physical block reduces waste on the track by requiring fewer Inter-Block Gaps (IBG) and it reduces the number of I/O's required to read the data. The problem is that the maximum blocksize was limited by software to 32K. Since this isn't an even multiple of the track capacity on a 3390, the best blocksize would be a half track. SDB provided the means of letting the system calculate this without requiring the programmer to do the calculation. However, such an "optimum" blocksize is only relevant when processing sequential files. VSAM uses the CISIZE, so blocksize is irrelevant. For most PDS's there will be more short blocks because members are rarely large enough to use a half-track block. In load libraries, most of the records are irregular sizes, significantly smaller than the blocksize, so again, it doesn't do anything. Adam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Terminology - Datasets
I think that it's often a lot of fuss for nothing. I don't believe anyone is confused if I refer to a VSAM file, or a UNIX file, or a UNIX directory, or a PDS. Invariably we qualify what we are talking about when we have to be specific. Beyond that, I don't see it as particularly relevant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Porowski, Kenneth Sent: Wednesday, April 26, 2017 8:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Terminology - Datasets >From a z/OS - Mainframe perspective You have the UNIX filesystem with various types of files in it. You have the "classic" Mainframe datasets (sequential, PDS, VSAM, etc.) To differentiate the "classic" datasets from the UNIX filesystem/files what is the correct/preferred terminology for the "classic" datasets? MVS dataset MVS style dataset MVS type dataset z/OS dataset etc. something else? This email message and any accompanying materials may contain proprietary, privileged and confidential information of CIT Group Inc. or its subsidiaries or affiliates (collectively, “CIT”), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sent from or received at this email address. -- 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: Terminology - Datasets
Typically a "dataset" is MVS - z/OS, while a "file" is UNIX. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Porowski, Kenneth Sent: Wednesday, April 26, 2017 8:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Terminology - Datasets >From a z/OS - Mainframe perspective You have the UNIX filesystem with various types of files in it. You have the "classic" Mainframe datasets (sequential, PDS, VSAM, etc.) To differentiate the "classic" datasets from the UNIX filesystem/files what is the correct/preferred terminology for the "classic" datasets? MVS dataset MVS style dataset MVS type dataset z/OS dataset etc. something else? This email message and any accompanying materials may contain proprietary, privileged and confidential information of CIT Group Inc. or its subsidiaries or affiliates (collectively, “CIT”), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sent from or received at this email address. -- 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: Draining JES2 SPOOL volume
I see that part of the problem may be identifying the job that is holding spool space. I suggested spool offload, as a possible way to either (1) move existing data, or (2) identify job holding it. If you know the job, then you might be able to use the $Tjob command to SPIN the data currently on the spool if the job is still active. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, January 24, 2017 3:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Draining JES2 SPOOL volume You might find it easier to create one new spool volume to juggle output around. When you're all done, you can drop that temporary volume. In general, output on a spool volume that prevents it from being taken offline (drained) is, as others have said, output that is viewed as 'active'. This could be long running tasks or something as simple as syslog. If you put a volume in draining status and then IPL each JES member (one at a time), you will most likely end up with a volume that be taken offline. That process is a PITA in practice, which is why IBM invented the spool migration function. You might, as I said above, find it easier to add a temporary volume to migrate to, then migrate back at the end. I don't recall seeing your actual motivation and goal for doing all this. I might help us give better advice. . . 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 Gerhard Adam Sent: Tuesday, January 24, 2017 2:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Draining JES2 SPOOL volume Also, if the objective is simply to free the data to drain the spool volume, have you tried Spool Offload? Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis G Sent: Tuesday, January 24, 2017 2:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Draining JES2 SPOOL volume On Jan 24, 2017, at 4:12 PM, Gerhard Adam wrote: > > Have you looked at, or tried the $MSPL command? I looked at it, but it didn’t fit what I was trying to do. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- 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: Draining JES2 SPOOL volume
Ok, so how about spool offload? Sent from my iPhone > On Jan 24, 2017, at 2:55 PM, Pew, Curtis G > wrote: > >> On Jan 24, 2017, at 4:46 PM, Gerhard Adam wrote: >> >> I'm confused. I thought you were trying to drain a spool volume? What >> could be more relevant, then the command intended to accelerate that by >> migrating spool data? > > To migrate, you have to have a suitable target volume, which is not the case > for me. > > (I actually tried to migrate to one of the other SPOOL volumes, but they all > said there wasn’t a large enough free extent.) > > -- > Pew, Curtis G > curtis@austin.utexas.edu > ITS Systems/Core/Administrative Services > > > -- > 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: Draining JES2 SPOOL volume
Also, if the objective is simply to free the data to drain the spool volume, have you tried Spool Offload? Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis G Sent: Tuesday, January 24, 2017 2:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Draining JES2 SPOOL volume On Jan 24, 2017, at 4:12 PM, Gerhard Adam wrote: > > Have you looked at, or tried the $MSPL command? I looked at it, but it didn’t fit what I was trying to do. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- 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: Draining JES2 SPOOL volume
I'm confused. I thought you were trying to drain a spool volume? What could be more relevant, then the command intended to accelerate that by migrating spool data? Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pew, Curtis G Sent: Tuesday, January 24, 2017 2:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Draining JES2 SPOOL volume On Jan 24, 2017, at 4:12 PM, Gerhard Adam wrote: > > Have you looked at, or tried the $MSPL command? I looked at it, but it didn’t fit what I was trying to do. -- Pew, Curtis G curtis@austin.utexas.edu ITS Systems/Core/Administrative Services -- 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: Draining JES2 SPOOL volume
Have you looked at, or tried the $MSPL command? Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, January 24, 2017 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Draining JES2 SPOOL volume Exactly what I was going to suggest. However, the volume will not complete the drain until empty. This *may* take weeks, depending on your installations choices. YMMV. This may require a major subsystem be bounced so the output can be purged. I have seen cases where a JES restart was required to free the spool space. Draining/restarting initiators is also helpful. Spool Offload can also be a big help here. Use the output of the $DSPL command to process as much as you can prior to restarts You may get luck. IIRC, as of JES 2.1 there is a variation of the Drain command that causes the spool data to be migrated to the remaining volumes. HTH, Try $djq(*),spl-(splz00) It's probably an STC, maybe a TSU ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- 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: Looking for USERMOD samples
What you have will look something like this: //SMPCNTL DD * SET BDY(GLOBAL). RECEIVE SELECT(FMN2001) SYSMODS. SET BDY (TARGET). APPLY SELECT(FMN2001) RETRY(YES) REDO. /* //SMPPTFIN DD DATA,DLM=$$ ++USERMOD (FMN2001) REWORK(201601) . ++VER (Z038) FMID(JADLD12) PRE(UI25246) . ++JCLIN. // EXEC PGM=IEBCOPY //DISTDD DD DSN=distribution library,DISP=SHR [NOTE: make the DD statement that on the DISTMOD parameter]. //TARGLIB DD DSN=target.library,DISP=SHR [NOTE: DD statement must reflect target library] //SYSIN DD * COPY OUTDD=TARGLIB,INDD=DISTDD /* ++SRC(FMN2POPT) TXLIB(FMN2SRC) DISTLIB(AFMNSAM1) DISTMOD(distribution load library). *** Source code follows *** This should be all you need. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Tuesday, December 27, 2016 2:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for USERMOD samples W dniu 2016-12-27 o 22:54, Paul Gilmartin pisze: > On 2016-12-27 14:47, R.S. wrote: >> I'm trying to learn a little bit about SMP/E usermods. >> Unfortunately neither SMP/E manuals nor google did not provide good (*well explained*) samples. >> >> >> Example (from File Manager): >> //SMPCNTL DD * >> SET BDY(GLOBAL). >> RECEIVE SELECT(FMN2001) SYSMODS. >> SET BDY (TARGET). >> APPLY SELECT(FMN2001) RETRY(YES) REDO. >> /* >> //SMPPTFIN DD DATA,DLM=$$ >> ++USERMOD (FMN2001) REWORK(201601) . >> ++VER (Z038) FMID(JADLD12) PRE(UI25246) . >> ++JCLIN. >> /* >> ++SRC(FMN2POPT) TXLIB(FMN2SRC) DISTLIB(AFMNSAM1). >> $$ >> FMN2SRC is a DD name pointing to a member with source code. >> Q1: How can I know what's target library for the load module? >> Q2: there is no assemble or linkedit jobstep. I assume it comes from SMP/E. >> Q3: FMN2SRC DD - should it describe library or member? In other words: DSN=MY.LIB or DSN=MY.LIB(MEM) ? >> > A TXLIB is a library in which APPLY (I think) will save member FNM2POPT. > With the options coded, the assembler source of FNM2POPT should appear > inline, after the ++SRC. There are other ways; I'd need to RTFM to say more. > > You'll need to allocate FNM2SRC in JCL and/or have a DDDEF for it. > TXLIB is a library with source code. SMPE/ Reference: TXLIB is the ddname of the partitioned data set containing the source. Similar description can be found in FMN.SFMNSAM1 (a source of the job quoted above). Although the role of DISTLIB is not 100% clear for me, but definitely it's not target library. Regards -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych. -- 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: Looking for USERMOD samples
Look in the SMP/E Reference manual, in the section for ++SRC. There are some specific examples that will help. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, December 27, 2016 1:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Looking for USERMOD samples On 2016-12-27 14:47, R.S. wrote: > I'm trying to learn a little bit about SMP/E usermods. > Unfortunately neither SMP/E manuals nor google did not provide good (*well explained*) samples. > > > Example (from File Manager): > //SMPCNTL DD * > SET BDY(GLOBAL). > RECEIVE SELECT(FMN2001) SYSMODS. > SET BDY (TARGET). > APPLY SELECT(FMN2001) RETRY(YES) REDO. > /* > //SMPPTFIN DD DATA,DLM=$$ > ++USERMOD (FMN2001) REWORK(201601) . > ++VER (Z038) FMID(JADLD12) PRE(UI25246) . > ++JCLIN. > /* > ++SRC(FMN2POPT) TXLIB(FMN2SRC) DISTLIB(AFMNSAM1). > $$ > FMN2SRC is a DD name pointing to a member with source code. > Q1: How can I know what's target library for the load module? > Q2: there is no assemble or linkedit jobstep. I assume it comes from SMP/E. > Q3: FMN2SRC DD - should it describe library or member? In other words: DSN=MY.LIB or DSN=MY.LIB(MEM) ? > A TXLIB is a library in which APPLY (I think) will save member FNM2POPT. With the options coded, the assembler source of FNM2POPT should appear inline, after the ++SRC. There are other ways; I'd need to RTFM to say more. You'll need to allocate FNM2SRC in JCL and/or have a DDDEF for it. -- gil -- 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: new JES2 MAS jobs will not run on member 2
Correct. Those define NJE APPL's ... -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Monday, December 5, 2016 5:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: new JES2 MAS jobs will not run on member 2 and along those lines I think my other issue is I don't need APPL(LITJES2A) NODE=1 <-- this is member( 1) APPL(LITJES2C) NODE=1 <--- this is member(2) APPL(LITJES2T) NODE=2 APPL(A6504JEA) NODE=4 - Original Message - From: "Gerhard Adam" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, December 5, 2016 7:40:12 AM Subject: Re: new JES2 MAS jobs will not run on member 2 I'm sorry, but it seems that you're trying to set up an NJE node but you're calling it a MAS. A MAS doesn't require anything, except that the SPOOL and CKPT parameters point to the same data set. That's it. There's nothing else required. All these references to MEMBER and OWNMEMB are NJE definitions. If it's the latter you want, then you need a network connection and you need to ensure it is started before the systems will recognize each other. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vitullo, Carmen P Sent: Sunday, December 4, 2016 2:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: new JES2 MAS jobs will not run on member 2 Easier for this situation to do an IPL, since both systems jes2parms were needing change I used a jobparm to direct the job to the correct system, but now that you mention this, I really didn't need it since member 2 has only one specific class Carmen Vitullo Lead Systems Programmer Arkansas Blue Cross and Blue Shield IT Infrastructure Services 515 West Pershing Blvd. North Little Rock, Arkansas 72114 Office: 501.210.4705 Cell: 501.514.4266 cpvitu...@arkbluecross.com arkansasbluecross.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Sunday, December 04, 2016 3:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: new JES2 MAS jobs will not run on member 2 Not sure what you're doing but a MAS certainly doesn't require an IPL, nor does it use the /*JOBPARM statement. If there is an initiator available, it will pick up the job. Sent from my iPhone > On Dec 4, 2016, at 1:13 PM, Vitullo, Carmen P > wrote: > > I just brought 2 systems into a JES2MAS everything looked OK, some fat > finger issues, and an IPL and all OK Testing the batch submitting I > submit job from member 1 to member 2 using /*JOBPARM S=memb2 Job sits > on JES2 queue awaiting conversion - I've tried everything with node > and member statements and nothing works If I submit from member 2 the > jobs still sits in the input queue, now showing the correct class, Has anyone seen this type of issue? my first time bringing 2 systems into a MAS, What am I missing ? > Thanks > > > > Carmen Vitullo > Lead Systems Programmer > > Arkansas Blue Cross and Blue Shield > IT Infrastructure Services > 515 West Pershing Blvd. > North Little Rock, Arkansas 72114 > Office: 501.210.4705 > Cell: 501.514.4266 > cpvitu...@arkbluecross.com > arkansasbluecross.com > > > > IBM-MAIN > > -- > Privacy Information: http://privacynotice.net (data rate charges may > apply) or 800-524-2621. > > -- > Privacy Information: http://privacynotice.net (data rate charges may > apply) or 800-524-2621. > > -- > 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 -- Privacy Information: http://privacynotice.net (data rate charges may apply) or 800-524-2621. -- Privacy Information: http://privacynotice.net (data rate charges may apply) or 800-524-2621. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: new JES2 MAS jobs will not run on member 2
One correction to my previous comment ... you also need a MASDEF parameter. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vitullo, Carmen P Sent: Sunday, December 4, 2016 2:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: new JES2 MAS jobs will not run on member 2 Easier for this situation to do an IPL, since both systems jes2parms were needing change I used a jobparm to direct the job to the correct system, but now that you mention this, I really didn't need it since member 2 has only one specific class Carmen Vitullo Lead Systems Programmer Arkansas Blue Cross and Blue Shield IT Infrastructure Services 515 West Pershing Blvd. North Little Rock, Arkansas 72114 Office: 501.210.4705 Cell: 501.514.4266 cpvitu...@arkbluecross.com arkansasbluecross.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Sunday, December 04, 2016 3:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: new JES2 MAS jobs will not run on member 2 Not sure what you're doing but a MAS certainly doesn't require an IPL, nor does it use the /*JOBPARM statement. If there is an initiator available, it will pick up the job. Sent from my iPhone > On Dec 4, 2016, at 1:13 PM, Vitullo, Carmen P wrote: > > I just brought 2 systems into a JES2MAS everything looked OK, some fat > finger issues, and an IPL and all OK Testing the batch submitting I > submit job from member 1 to member 2 using /*JOBPARM S=memb2 Job sits > on JES2 queue awaiting conversion - I've tried everything with node > and member statements and nothing works If I submit from member 2 the > jobs still sits in the input queue, now showing the correct class, Has anyone seen this type of issue? my first time bringing 2 systems into a MAS, What am I missing ? > Thanks > > > > Carmen Vitullo > Lead Systems Programmer > > Arkansas Blue Cross and Blue Shield > IT Infrastructure Services > 515 West Pershing Blvd. > North Little Rock, Arkansas 72114 > Office: 501.210.4705 > Cell: 501.514.4266 > cpvitu...@arkbluecross.com > arkansasbluecross.com > > > > IBM-MAIN > > -- > Privacy Information: http://privacynotice.net (data rate charges may > apply) or 800-524-2621. > > -- > Privacy Information: http://privacynotice.net (data rate charges may > apply) or 800-524-2621. > > -- > 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 -- Privacy Information: http://privacynotice.net (data rate charges may apply) or 800-524-2621. -- Privacy Information: http://privacynotice.net (data rate charges may apply) or 800-524-2621. -- 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: new JES2 MAS jobs will not run on member 2
I'm sorry, but it seems that you're trying to set up an NJE node but you're calling it a MAS. A MAS doesn't require anything, except that the SPOOL and CKPT parameters point to the same data set. That's it. There's nothing else required. All these references to MEMBER and OWNMEMB are NJE definitions. If it's the latter you want, then you need a network connection and you need to ensure it is started before the systems will recognize each other. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vitullo, Carmen P Sent: Sunday, December 4, 2016 2:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: new JES2 MAS jobs will not run on member 2 Easier for this situation to do an IPL, since both systems jes2parms were needing change I used a jobparm to direct the job to the correct system, but now that you mention this, I really didn't need it since member 2 has only one specific class Carmen Vitullo Lead Systems Programmer Arkansas Blue Cross and Blue Shield IT Infrastructure Services 515 West Pershing Blvd. North Little Rock, Arkansas 72114 Office: 501.210.4705 Cell: 501.514.4266 cpvitu...@arkbluecross.com arkansasbluecross.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Sunday, December 04, 2016 3:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: new JES2 MAS jobs will not run on member 2 Not sure what you're doing but a MAS certainly doesn't require an IPL, nor does it use the /*JOBPARM statement. If there is an initiator available, it will pick up the job. Sent from my iPhone > On Dec 4, 2016, at 1:13 PM, Vitullo, Carmen P wrote: > > I just brought 2 systems into a JES2MAS everything looked OK, some fat > finger issues, and an IPL and all OK Testing the batch submitting I > submit job from member 1 to member 2 using /*JOBPARM S=memb2 Job sits > on JES2 queue awaiting conversion - I've tried everything with node > and member statements and nothing works If I submit from member 2 the > jobs still sits in the input queue, now showing the correct class, Has anyone seen this type of issue? my first time bringing 2 systems into a MAS, What am I missing ? > Thanks > > > > Carmen Vitullo > Lead Systems Programmer > > Arkansas Blue Cross and Blue Shield > IT Infrastructure Services > 515 West Pershing Blvd. > North Little Rock, Arkansas 72114 > Office: 501.210.4705 > Cell: 501.514.4266 > cpvitu...@arkbluecross.com > arkansasbluecross.com > > > > IBM-MAIN > > -- > Privacy Information: http://privacynotice.net (data rate charges may > apply) or 800-524-2621. > > -- > Privacy Information: http://privacynotice.net (data rate charges may > apply) or 800-524-2621. > > -- > 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 -- Privacy Information: http://privacynotice.net (data rate charges may apply) or 800-524-2621. -- Privacy Information: http://privacynotice.net (data rate charges may apply) or 800-524-2621. -- 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
