Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
Thats because the IBMers understood the code and had the source Peter, Thats because the IBMers understood the code and had the source. The customer on the other hand at the time of pre-OCO had the source and the PLMs. Since at the time the source and PLMs were considered the lawsigh After working for now this my second software vendor, first being Legent , no CA-Legent, I understand the source issue. Scott J Ford From: Peter Relson rel...@us.ibm.com To: IBM-MAIN@bama.ua.edu Sent: Wednesday, December 17, 2008 8:53:22 AM Subject: Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions) Uh, reduce cost by eliminating Program Logic doc? I assume the PLM was replaced by something else for internal use. Eliminating doc for program logic seems like a good way to also eliminate program logic. There's a lot of assuming going on in the posts of the last few days. This assumption too is incorrect in a way. For the most part, no one actually used the PLMs internally either. The information from the PLMs was already available for us within the modules themselves (mostly). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
The PLMs and source code in CICS 1.4 ...remember those days sav Jim, The PLMs and source code in CICS 1.4 ...remember those days saved my bacon too many times to count. My first CICS shop was a Cobol Macro shop and a lot of ASRA's...Also won several bets with application programmers when their code did wierd branches etc with bad subscripts because I knoew CICS code... Scott J Ford From: Jim Mulder d10j...@us.ibm.com To: IBM-MAIN@bama.ua.edu Sent: Wednesday, December 17, 2008 2:53:38 AM Subject: Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions) IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 12/16/2008 09:57:39 PM: ... the mid 1990s, and somewhere around then production of PLMs (internal and external) ceased in order to reduce development costs. Uh, reduce cost by eliminating Program Logic doc? I assume the PLM was replaced by something else for internal use. Eliminating doc for program logic seems like a good way to also eliminate program logic. PLMs were not internally replaced by any coherant strategy. Some components maintained theirs for a while in TSO data sets, other components did other things (component workbooks, whatever). Others did nothing. Now with worries about an aging carbon-based life form knowledge base, and Wikis being all the rage, now and then there is some excitmemnt about trying to organize that kind of information for internal use. A lot of labor went into writing, maintaining, and producing PLMs, so eliminating them of course immediately reduced some costs. Now, whether or not the benefits of PLMs provided a positive return on investment, and more was lost than was saved by eliminating them, I don't know how to measure that. I am just trying to relate a little of the history as I recall it. BTW, I vaguely recall the before the external PLMs disappeared, some of them had changed format, with diagrams of logic flow being replaced with something else. HIPO diagrams or something like that? That helped lessen the blow of the PLM's demise. First replace it with something useless; then ease the pain by removing the PLM altogether. [insert a scarcasty here if you have one.] Was I the only one that did not like that change? For assembler programs, there was program called FL1 or some such thing that produced flowcharts from special block comment comments imbedded in the code. That is why you would see comments like */* P RESET SVC FLIH SUPER BIT, RESTORE NORMAL FRR STACK */@G381PXU */* P ENABLE PSW FOR I/O EXTERNAL INTERRUPTS */@G381PXU */* D (NO,SVCENTPT,YES,CMSCK) ANY MORE LOCKS */@G381PXU I never coded this stuff myself - I would guess that P produced a process box, and D produced a decision box. This was already falling out of use when I got here in 1979, and the amount of assembler source was continuing to diminish in favor of PL/whatever. HIPOs were becoming the rage in the IBM internal programming classes for new hires, and I probably still have a green plastic HIPO template (similar to to old plastic flowchart templates) stuffed in a drawer somewhere. There was a program called the logic tool that produced HIPO-ish stuff for PLMs from block comments in PL/whatever source code. That is why you may have seen block comments starting with Title: or Logic: , and line comments starting with L: . Some development groups were very much into this stuff, others were not. The PIG (Processor Interface Group, that owned MVS reconfiguration, SADMP, machine check handler, etc in the mid 1980s) loved this stuff, and would develop new modules by first writing the block comments, and then hold design reviews in their meeting room (the PIG pen) of the logic tool output, with great attention to detail on the esthetic beauty of the results. Of course, the ratio of amount of code to programmers was drastically lower in those days. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
we have more broken interfaces (or badly sprained interfaces). Examples, please. By a broken interface do you mean an interface that used to work that no longer does (and for which there was no migration information provided or, for ISVs, notification)? Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
Both are often necessary -- the PLM tells you what the author MEANT to happen. Your assumption is that author of the code and the author of the PLM are one and the same. My assumption is otherwise. Date: Wed, 17 Dec 2008 08:06:34 -0500 From: zosw...@gmail.com Subject: Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions) To: IBM-MAIN@bama.ua.edu Both are often necessary -- the PLM tells you what the author MEANT to happen. ObAnecdote: I supported a set of products that I knew nothing about, had no PLM, no original author to consult. I wound up calling my favorite customer about once a month to ask what he thought it SHOULD be doing in a particular case... On Wed, Dec 17, 2008 at 7:55 AM, J R jayare...@hotmail.com wrote: With source code available, the PLMs were a distraction. If you looked at the code, you *knew* what was happening. If you looked at the PLM, you saw what the author *thought* was happening. Of course, when the code was no longer accessible, the PLM was the next best thing. That's how *this* dino evolved. _ Suspicious message? There’s an alert for that. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad2_122008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
We used use source code and PLMs to understand the workings of a lot of the VM and MVS components. Thats how a lot of us dinos evolvedlol With source code available, the PLMs were a distraction. If you looked at the code, you *knew* what was happening. If you looked at the PLM, you saw what the author *thought* was happening. Of course, when the code was no longer accessible, the PLM was the next best thing. That's how *this* dino evolved. Date: Tue, 16 Dec 2008 10:47:29 -0800 From: scott_j_f...@yahoo.com Subject: Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions) To: IBM-MAIN@bama.ua.edu I just had this conversation with someone. We used use source code and PLMs to understand the workings of a lot of the VM and MVS components. Thats how a lot of us dinos evolvedlol Scott J Ford _ Send e-mail anywhere. No map, no compass. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhere_122008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
Both are often necessary -- the PLM tells you what the author MEANT to happen. ObAnecdote: I supported a set of products that I knew nothing about, had no PLM, no original author to consult. I wound up calling my favorite customer about once a month to ask what he thought it SHOULD be doing in a particular case... On Wed, Dec 17, 2008 at 7:55 AM, J R jayare...@hotmail.com wrote: With source code available, the PLMs were a distraction. If you looked at the code, you *knew* what was happening. If you looked at the PLM, you saw what the author *thought* was happening. Of course, when the code was no longer accessible, the PLM was the next best thing. That's how *this* dino evolved. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
I agree that also how I learned. But it was also some really good Jay, I agree that also how I learned. But it was also some really good guys/gals around me who taught by example... The PSRs - you'all remember these folks... Scott J Ford From: J R jayare...@hotmail.com To: IBM-MAIN@bama.ua.edu Sent: Wednesday, December 17, 2008 9:10:39 AM Subject: Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions) Both are often necessary -- the PLM tells you what the author MEANT to happen. Your assumption is that author of the code and the author of the PLM are one and the same. My assumption is otherwise. Date: Wed, 17 Dec 2008 08:06:34 -0500 From: zosw...@gmail.com Subject: Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions) To: IBM-MAIN@bama.ua.edu Both are often necessary -- the PLM tells you what the author MEANT to happen. ObAnecdote: I supported a set of products that I knew nothing about, had no PLM, no original author to consult. I wound up calling my favorite customer about once a month to ask what he thought it SHOULD be doing in a particular case... On Wed, Dec 17, 2008 at 7:55 AM, J R jayare...@hotmail.com wrote: With source code available, the PLMs were a distraction. If you looked at the code, you *knew* what was happening. If you looked at the PLM, you saw what the author *thought* was happening. Of course, when the code was no longer accessible, the PLM was the next best thing. That's how *this* dino evolved. _ Suspicious message? There’s an alert for that. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_broad2_122008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
Uh, reduce cost by eliminating Program Logic doc? I assume the PLM was replaced by something else for internal use. Eliminating doc for program logic seems like a good way to also eliminate program logic. There's a lot of assuming going on in the posts of the last few days. This assumption too is incorrect in a way. For the most part, no one actually used the PLMs internally either. The information from the PLMs was already available for us within the modules themselves (mostly). Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick O'Keefe Sent: Tuesday, December 16, 2008 8:58 PM To: IBM-MAIN@bama.ua.edu Subject: Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions) On Tue, 16 Dec 2008 18:04:13 -0500, Jim Mulder d10j...@us.ibm.com wrote: PLMs. sigh IBM's promise to improve the doc included getting rid of PLMs. That way there wasn't as much information to go obsolete. ... That's not exactly how things happened. SNIP BTW, I vaguely recall the before the external PLMs disappeared, some of them had changed format, with diagrams of logic flow being replaced with something else. HIPO diagrams or something like that? That helped lessen the blow of the PLM's demise. First replace it with something useless; then ease the pain by removing the PLM altogether. [insert a scarcasty here if you have one.] Was I the only one that did not like that change? SNIP Between 1991 and 2003, I noticed more and more violations of the IBM Internal Standards Manual. I have even had IBM people tell me that such didn't exist, but I had one in my hot little hands in 1991 at STL. As a contractor, I was required to follow it. Seems that since then, with the cost cutting things, loss of continuity (by early retirement and such), new people coming in and writing code in other than PLxx or ALC (while NOT having an MVS background), we have more broken interfaces (or badly sprained interfaces). So, it would seem to me that IBM would really want to back off OCO a bit so that things could be better fixed and/or understood by the customers. After all, as someone I know said, This is a concrete pond. And we are in drought conditions. [Referring to IBM mainframe installations.] Regards, Steve Thompson -- Opinions expressed by this poster are not necessarily those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
On Wed, 17 Dec 2008 09:10:39 -0500, J R wrote: Both are often necessary -- the PLM tells you what the author MEANT to happen. Your assumption is that author of the code and the author of the PLM are one and the same. My assumption is otherwise. The crucial question here is whether the code was written from the PLM, or the PLM was reverse-engineered from the code. I suspect that among diverse environments both happened. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
In listserv%200812161438323331.0...@bama.ua.edu, on 12/16/2008 at 02:38 PM, John McKown joa...@swbell.net said: A bit off, but has anybody else here looked at the i system (nee AS/400)? You want to talk about OCO! It has some really interesting capabilities. But it has NO way to write anything in assembler. When did that change? Back on the S/38 IBM documented MI and how to compile an MI program into a program object. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
In blu137-w44922139159bd12250142ea3...@phx.gbl, on 12/17/2008 at 07:55 AM, J R jayare...@hotmail.com said: With source code available, the PLMs were a distraction. Not the good ones, e.g, MVT Supervisor. If you looked at the code, you *knew* what was happening. Locally. The PLM (sometimes) explained how the modules fit together. Of course, when the code was no longer accessible, the PLM was the next best thing. Except that I was used to looking at the code to clarify what the PLM said :-( -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
In 6.2.1.2.2.20081211140035.05aac...@127.0.0.1, on 12/11/2008 at 02:13 PM, Arthur T. ibmm...@intergate.com said: It's been a long time since IBM went OCO. When they did, didn't they promise better documentation to make up for the inability to see what the programs are actually doing? ObFlounder Yes, and they broke that promise before the ink was dry. In some cases the documentation actually got worse. He deserves better than being talked down to. He is rude enough that I don't see where he has a valid claim to curtesy. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
On 16 Dec 2008 09:10:39 -0800, shmuel+ibm-m...@patriot.net (Shmuel Metz , Seymour J.) wrote: He deserves better than being talked down to. He is rude enough that I don't see where he has a valid claim to curtesy. There is some value in being courteous for your own sake. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
I just had this conversation with someone. We used use source code and PLMs to understand the workings of a lot of the VM and MVS components. Thats how a lot of us dinos evolvedlol Scott J Ford From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net To: IBM-MAIN@bama.ua.edu Sent: Tuesday, December 16, 2008 11:59:07 AM Subject: Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions) In 6.2.1.2.2.20081211140035.05aac...@127.0.0.1, on 12/11/2008 at 02:13 PM, Arthur T. ibmm...@intergate.com said: It's been a long time since IBM went OCO. When they did, didn't they promise better documentation to make up for the inability to see what the programs are actually doing? ObFlounder Yes, and they broke that promise before the ink was dry. In some cases the documentation actually got worse. He deserves better than being talked down to. He is rude enough that I don't see where he has a valid claim to curtesy. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
On Tue, 16 Dec 2008 10:47:29 -0800, Scott Ford scott_j_f...@yahoo.com wrote: ... source code and PLMs to understand the workings of a lot of the VM and MVS components. ... PLMs. sigh IBM's promise to improve the doc included getting rid of PLMs. That way there wasn't as much information to go obsolete. We are so much off now without all that confusing (and occassionally incorrect) detail. We should all be happy. I guess. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
On Tue, 16 Dec 2008 14:28:53 -0600, Patrick O'Keefe patrick.oke...@wamu.net wrote: On Tue, 16 Dec 2008 10:47:29 -0800, Scott Ford scott_j_f...@yahoo.com wrote: ... source code and PLMs to understand the workings of a lot of the VM and MVS components. ... PLMs. sigh IBM's promise to improve the doc included getting rid of PLMs. That way there wasn't as much information to go obsolete. We are so much off now without all that confusing (and occassionally incorrect) detail. We should all be happy. I guess. Pat O'Keefe A bit off, but has anybody else here looked at the i system (nee AS/400)? You want to talk about OCO! It has some really interesting capabilities. But it has NO way to write anything in assembler. The OS is basically divided in two. The high level part is called OS/400 (i5/OS). It is written at the MI (Machine Independent) level. The low level part is called the SLIC (System Licensed Internal Code). None of this code is ever shown outside of the AS/400 development lab. You cannot even write your own language! Because you cannot create a program object. And something can be executed only if it is marked as a program object. This is not a system for bits-n-bytes techies! You simply cannot get to the bits-n-bytes level. -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
The constant thing about change is change. I saw your note about SOA. That is why I started getting educated ( on my own ) into the web technologies. My kids still need shoes to wear, so hence i have work like everone else to make money, can't retire yet...sigh Scott J Ford From: Patrick O'Keefe patrick.oke...@wamu.net To: IBM-MAIN@bama.ua.edu Sent: Tuesday, December 16, 2008 3:28:53 PM Subject: Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions) On Tue, 16 Dec 2008 10:47:29 -0800, Scott Ford scott_j_f...@yahoo.com wrote: ... source code and PLMs to understand the workings of a lot of the VM and MVS components. ... PLMs. sigh IBM's promise to improve the doc included getting rid of PLMs. That way there wasn't as much information to go obsolete. We are so much off now without all that confusing (and occassionally incorrect) detail. We should all be happy. I guess. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
On Tue, 16 Dec 2008 14:38:32 -0600, John McKown wrote: A bit off, but has anybody else here looked at the i system (nee AS/400)? You want to talk about OCO! It has some really interesting capabilities. But it has NO way to write anything in assembler. The OS is basically divided in two. The high level part is called OS/400 (i5/OS). It is written at the MI (Machine Independent) level. The low level part is called the SLIC (System Licensed Internal Code). None of this code is ever shown outside of the AS/400 development lab. You cannot even write your own language! Because you cannot create a program object. And something can be executed only if it is marked as a program object. This is not a system for bits-n-bytes techies! You simply cannot get to the bits-n-bytes level. So no ISVs? Or they code at the MI level. But I could draw a parallel to z: SLIC == microcode, millicode MI == assembler for z. Mac OS was somewhat like that, through OS 6 or so. But ISVs were allowed to span the boundary, and produced languages that allowed end users to span the gap likewise. OK. Through OS 6, Mac was sold with no networking software and no way to create an executable. But it could read PC diskettes. And nerds of a certain persuasion flamed about being unable to download software to PCs and run it on Macs, because it was not marked executable on the PC disk. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
On Tue, 16 Dec 2008 15:23:08 -0600, Paul Gilmartin paulgboul...@aim.com wrote: So no ISVs? Or they code at the MI level. Sorry. There are ISVs. But only for application level code, not system level. IBM supplies compilers for COBOL, RPG, CL (similar to CLIST), C/C++, Java, and maybe other languages. But you cannot create a compiler because the interface to create an MI level program does not exist (no assembler). You could write a interpreter in C/C++, I guess. But that would slow down the language. But I could draw a parallel to z: SLIC == microcode, millicode Right. Remember all the microcode assists for the various OSes on various models of the S/370? The AS/400 is like that, but even more so. A great deal of the OS (including the database) is embedded in the SLIC. MI == assembler for z. Right. Except no HLASM-like language and so no way to program in assembler (at the MI level). snip -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
PLMs. sigh IBM's promise to improve the doc included getting rid of PLMs. That way there wasn't as much information to go obsolete. We are so much off now without all that confusing (and occassionally incorrect) detail. We should all be happy. I guess. That's not exactly how things happened. For OCO components, the PLMs and microfiche were colored pink, given a rather high security classification, and made available only within IBM with a lot of security rigimarole. But we did continue to produce external (for non-OCO stuff) and pink pages (for OCO stuff) PLMs up to about SP5.2.0. By then we were into the do more with less cost of the mid 1990s, and somewhere around then production of PLMs (internal and external) ceased in order to reduce development costs. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
On Tue, 16 Dec 2008 18:04:13 -0500, Jim Mulder d10j...@us.ibm.com wrote: PLMs. sigh IBM's promise to improve the doc included getting rid of PLMs. That way there wasn't as much information to go obsolete. ... That's not exactly how things happened. I assume nobody will be surprised to hear I didn't believe what I wrote, but I didn't know what emoticon to attach to it. Is there a sarcasty? ... the mid 1990s, and somewhere around then production of PLMs (internal and external) ceased in order to reduce development costs. Uh, reduce cost by eliminating Program Logic doc? I assume the PLM was replaced by something else for internal use. Eliminating doc for program logic seems like a good way to also eliminate program logic. BTW, I vaguely recall the before the external PLMs disappeared, some of them had changed format, with diagrams of logic flow being replaced with something else. HIPO diagrams or something like that? That helped lessen the blow of the PLM's demise. First replace it with something useless; then ease the pain by removing the PLM altogether. [insert a scarcasty here if you have one.] Was I the only one that did not like that change? Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 12/16/2008 09:57:39 PM: ... the mid 1990s, and somewhere around then production of PLMs (internal and external) ceased in order to reduce development costs. Uh, reduce cost by eliminating Program Logic doc? I assume the PLM was replaced by something else for internal use. Eliminating doc for program logic seems like a good way to also eliminate program logic. PLMs were not internally replaced by any coherant strategy. Some components maintained theirs for a while in TSO data sets, other components did other things (component workbooks, whatever). Others did nothing. Now with worries about an aging carbon-based life form knowledge base, and Wikis being all the rage, now and then there is some excitmemnt about trying to organize that kind of information for internal use. A lot of labor went into writing, maintaining, and producing PLMs, so eliminating them of course immediately reduced some costs. Now, whether or not the benefits of PLMs provided a positive return on investment, and more was lost than was saved by eliminating them, I don't know how to measure that. I am just trying to relate a little of the history as I recall it. BTW, I vaguely recall the before the external PLMs disappeared, some of them had changed format, with diagrams of logic flow being replaced with something else. HIPO diagrams or something like that? That helped lessen the blow of the PLM's demise. First replace it with something useless; then ease the pain by removing the PLM altogether. [insert a scarcasty here if you have one.] Was I the only one that did not like that change? For assembler programs, there was program called FL1 or some such thing that produced flowcharts from special block comment comments imbedded in the code. That is why you would see comments like */* P RESET SVC FLIH SUPER BIT, RESTORE NORMAL FRR STACK */@G381PXU */* P ENABLE PSW FOR I/O EXTERNAL INTERRUPTS */@G381PXU */* D (NO,SVCENTPT,YES,CMSCK) ANY MORE LOCKS */@G381PXU I never coded this stuff myself - I would guess that P produced a process box, and D produced a decision box. This was already falling out of use when I got here in 1979, and the amount of assembler source was continuing to diminish in favor of PL/whatever. HIPOs were becoming the rage in the IBM internal programming classes for new hires, and I probably still have a green plastic HIPO template (similar to to old plastic flowchart templates) stuffed in a drawer somewhere. There was a program called the logic tool that produced HIPO-ish stuff for PLMs from block comments in PL/whatever source code. That is why you may have seen block comments starting with Title: or Logic: , and line comments starting with L: . Some development groups were very much into this stuff, others were not. The PIG (Processor Interface Group, that owned MVS reconfiguration, SADMP, machine check handler, etc in the mid 1980s) loved this stuff, and would develop new modules by first writing the block comments, and then hold design reviews in their meeting room (the PIG pen) of the logic tool output, with great attention to detail on the esthetic beauty of the results. Of course, the ratio of amount of code to programmers was drastically lower in those days. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
In 494125d7.1080...@bremultibank.com.pl, on 12/11/2008 at 03:38 PM, R.S. r.skoru...@bremultibank.com.pl said: There is absoluetely no explanation why should I use HZSAIEOF program despite IEFBR14 performs the same work. No. People say there are no stupid questions, The exception to that is a question that asserts something contrary to fact. Questions should ask, not state. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
Linda Mooney linda.lst...@comcast.net wrote in message news:121220080116.12355.4941bb7e0002409f30432216527966cc050...@comc ast.net... Hi John, (fun old story response to (Semi-humorous post warning.) post. And sometimes an 'exposure' is also a 'feature'. True story. a 'few' years ago we had a programmer who was a little shaky on disp coding, sometimes coding new,delete,catlg. Programmer had worked many years in a shop where the programmers did not do JCL. Sometimes there would be a special run with a clock time of 15-20 hours, and the most important output dataset coded - yeah, you guessed it :-) So, somebody, usually the programmer, would call me while the job was still running. I would mount the work pack private, and map the drive and remap every time the file took an extent. When the job when to good EOJ, and the file was deleted, I would absolute allocate each extent location with IEFBR14, concat in the extent order, output in one 'piece' and give it back to the programmer. Did that a number of times... Well, this brings up a deeply hidden memory: this is exactly the way I recovered a JES2 checkpoint dataset, in the time the JES2 did not ENQ it and someone (I won't tell you who) was cleaning up old left around jes checkpoints and spools and deleted one checkpoint too many. Kees. ** 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John Eells snip ... From the very name of HZSAIEOF, and the penchant of good programmers to pick meaningful names when possible, I will speculate that it might perhaps, just maybe, stand for Allocate (data set) Indicating End-Of-File. You guys didn't see this? Need more coffee today...? Where's that Craddock guy when you need him, anyway? (Oh, no! Now I've done it. Next time they name a program like this, they'll probably use a random character generator. Or maybe they'll name it something misleading instead. ... You mean, like IGDZILLA? :-) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
I was not annoyed by the questions, but I expected a responsible answer to my question of why. Anyone is free to wonder why and even ask why but should not expect that valuable time will be spent providing answers to questions for which there is no reason you should care. Almost everyone who participates in this forum (whether IBM, customer, or ISV) is doing so on their own dime and a lot of extremely valuable information is exchanged. That is a great thing. But never forget that it is all based on the good will of the participants. As John E kindly put it, we would not have created something that cost us time and effort if we didn't think (to the best of our knowledge) that it was needed. There is no clear description what is a difference between delete and deactivate, there are no clear guidelines explaining the purpose of both commands. There is always room for improved documentation when it is needed. If all that a HC user cares about is that the check not run again, there is no difference. One pretty obvious difference is that you can't activate something that is deleted. There is a section in the book that talks about delete vs refresh. And the description of refresh mentions delete then addnew. There is a lot of description of addnew including a section entitled But my check doesn't reappear after ADDNEW - what happened to it? There is absoluetely no explanation why should I use HZSAIEOF program despite IEFBR14 performs the same work. Nor will there or should there be some. You are assuming incorrectly that IEFBR14 performs the same work. It doesn't. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Names (was: Health Checker questions)
On Thu, 11 Dec 2008 19:06:41 -0500, John Eells ee...@us.ibm.com wrote: ... From the very name of HZSAIEOF, and the penchant of good programmers to pick meaningful names when possible, ... (Oh, no! Now I've done it. Next time they name a program like this, they'll probably use a random character generator. Or maybe they'll name it something misleading instead. If that isn't what happened this time, that is. And we're not telling.) ... ... the penchant of good programmers to pick meaningful names when possible ... unless cleverness happens to strike, of course. I have to go back 25 years or so, but the program Host Command Facility (HCF) had the module prefix CHF. Its main module was, as I recall, CHFNPIE or maybe CHFONPIE, or some thing very similar. Chiffon pie. Just the sort of descriptive name you'd intuitively pick for something sending commands to a remote processor. :-) Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Names (was: Health Checker questions)
2008/12/12 Patrick O'Keefe patrick.oke...@wamu.net: ... the penchant of good programmers to pick meaningful names when possible ... unless cleverness happens to strike, of course. I have to go back 25 years or so, but the program Host Command Facility (HCF) had the module prefix CHF. Its main module was, as I recall, CHFNPIE or maybe CHFONPIE, or some thing very similar. Chiffon pie. Just the sort of descriptive name you'd intuitively pick for something sending commands to a remote processor. :-) Sure. Same reason that SMP/E just happens to have a load module called GIMISEX, and JES2 has macros named $DILBERT and $DOGBERT. And of course there's IGDZILLA. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
undelete by E E is not undelete. It is refresh. The description of refresh probably describes nicely what it does (it is delete followed by addnew). It is up to you to understand the ramifications. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
Peter Relson wrote: undelete by E E is not undelete. It is refresh. The description of refresh probably describes nicely what it does (it is delete followed by addnew). It is up to you to understand the ramifications. Peter, I'm sorry. I don't know for what, but I apologize. My English is poor and I don't grasp all the nuances, but from your words I feel that my questions irritated you. I apologize for that again. I just wanted to know more about Healtch Checker which I want to use. I did RTFM, but - it's a pity - the documentation is not at state-of-the-art level. There is no clear description what is a difference between delete and deactivate, there are no clear guidelines explaining the purpose of both commands. There is absoluetely no explanation why should I use HZSAIEOF program despite IEFBR14 performs the same work. People say there are no stupid questions, but it seems there are irritating questions. -- Radoslaw Skorupka Lodz, Poland P.S. I really appreciate your technical knowledge and your contribution to the list. -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
On Thu, 11 Dec 2008 15:38:15 +0100, R.S. [EMAIL PROTECTED] wrote: There is absoluetely no explanation why should I use HZSAIEOF program despite IEFBR14 performs the same work. We often do not document -why- you need to do things a certain way, but simply tell you what you need to do. HZSAIEOF does processing that IEFBR14 does not perform. You might or might not notice the difference in all cases, but there is one, and so you should do as the documentation directs in order to avoid potential problems. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
Walt Farrell [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Thu, 11 Dec 2008 15:38:15 +0100, R.S. [EMAIL PROTECTED] wrote: There is absoluetely no explanation why should I use HZSAIEOF program despite IEFBR14 performs the same work. We often do not document -why- you need to do things a certain way, but simply tell you what you need to do. HZSAIEOF does processing that IEFBR14 does not perform. You might or might not notice the difference in all cases, but there is one, and so you should do as the documentation directs in order to avoid potential problems. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design This answer reminded me of my first reaction when I read Radoslaw's first remark about 'empty' datasets when comparing the IEFBR14 datasets to the HZSAIEOF dataset. 'Empty' is a relative indication, it relies on the dataset's LSTAR being filled and there are/were applications that *thouhgt* they did not need to set LSTAR, because it was 'their' dataset and nobody should care about the internal structure. System Logger was one that thought it unnecessary to set HURBA because DFDSS 'knew' about this. After several problems, this was changed such, that Logger at least set HURBA at first close, so other applications had some idea about the contents. Maybe HZSAIEOF does format the dataset, but does not make this visible from the outside, which I consider not very decent. Applications might not recognize this dataset as being special and that they should not try to handle it. Kees. ** 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
Vernooy, C.P. - SPLXM wrote: 'Empty' is a relative indication, it relies on the dataset's LSTAR being filled and there are/were applications that *thouhgt* they did not need to set LSTAR, because it was 'their' dataset and nobody should care about the internal structure. Walt, Kees, I did follow the procedures. It was not my intention to clame that HZSAIEOF is some kind of empty or unnecessary program. My only intention was to UNDERSTAND how it works. I fully understand and accept answer that HZSAIEOF does nothing in my case, but not in general case. I also understand another possibility that HZSAIEOF does something which I don't see or does only some checks. For example, JES2 spool looks like empty, but it's not. This is important to know this - I know some guy who did F - free unused space under ISPF, because he wanted to save some cylinders. Now he knows... What I learnt: 1. According to documentation I should use HZSAIEOF to prepare dataset for Health Checker, despite the dataset looks like empty, untouched. 2. Deactivate is always reversible, while delete is not (not always). I should use deactivate whenever I want to temporarily deactivate some check. Usually deleted checks can be undeleted, but it is not always possible. I also noticed (my experience, limited by nature) that irreversible deleted checks are back after IPL. I have some other questions about HC, but I fear to ask. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
There is absoluetely no explanation why should I use HZSAIEOF program despite IEFBR14 performs the same work. Do you know that for sure? We often do not document -why- you need to do things a certain way, but simply tell you what you need to do. I think the fact the documentation says to do it, because it is the initialisation/formatting programme should be a good enough answer to why?. User: such and such is not working! IBM: did you follow instructions? User: no. why should I? IBM: click! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
On Thu, 11 Dec 2008 16:54:41 +0100, R.S. [EMAIL PROTECTED] wrote: I have some other questions about HC, but I fear to ask. You should never fear to ask, though of course you may not get an answer or may not like the answer you get. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
OCO, documentation, support from IBM-Main, etc. (was Re: Health Checker questions)
On 11 Dec 2008 07:08:48 -0800, in bit.listserv.ibm-main (Message-ID:listserv%200812110906199610.1...@bama.ua.edu) wfarr...@us.ibm.com (Walt Farrell) wrote: On Thu, 11 Dec 2008 15:38:15 +0100, R.S. r.skoru...@bremultibank.com.pl wrote: There is absoluetely no explanation why should I use HZSAIEOF program despite IEFBR14 performs the same work. We often do not document -why- you need to do things a certain way, but simply tell you what you need to do. HZSAIEOF does processing that IEFBR14 does not perform. You might or might not notice the difference in all cases, but there is one, and so you should do as the documentation directs in order to avoid potential problems. It's been a long time since IBM went OCO. When they did, didn't they promise better documentation to make up for the inability to see what the programs are actually doing? Meanwhile, to Walt: Radoslaw has been a useful contributor to IBM-Main. He's done the RTFM step. He deserves better than being talked down to. If you're not allowed to give the answers he wants, you would sound less condescending to come right out and say so. How can he better his understanding if you're telling him he shouldn't even be asking the questions? Your answers to other questions have certainly been much more open and useful. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
On Sat, 6 Dec 2008 09:22:32 -0500, Peter Relson rel...@us.ibm.com wrote: ... A: Are you opposed for some reason to following instructions? Please use what is provided. ... I find this a distrubing statement. How many thousands of datasets would have blocksizes of 3120, 6144, or 8800 if obviously suspect directions had been followed? (And I bet there ae STILL ProgDirs around specifying those sizes.) How many userids would have Unix uid(0) unnecessarily? At the very least, unexpected directions should prompt questions. Why? What is the efffect of following the directions? What is the effect of NOT following the directions? With HZSAIEOF I would definitely wonder what its effect is on other than Health Checker. We're paid to wonder about things like that. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
Consider this: IEFBR14 doesn't write a EOF on the dataset. Could be a very important point. R.S. wrote: Peter Relson wrote: undelete by E E is not undelete. It is refresh. The description of refresh probably describes nicely what it does (it is delete followed by addnew). It is up to you to understand the ramifications. Peter, I'm sorry. I don't know for what, but I apologize. My English is poor and I don't grasp all the nuances, but from your words I feel that my questions irritated you. I apologize for that again. I just wanted to know more about Healtch Checker which I want to use. I did RTFM, but - it's a pity - the documentation is not at state-of-the-art level. There is no clear description what is a difference between delete and deactivate, there are no clear guidelines explaining the purpose of both commands. There is absoluetely no explanation why should I use HZSAIEOF program despite IEFBR14 performs the same work. People say there are no stupid questions, but it seems there are irritating questions. -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
Patrick O'Keefe wrote: snip At the very least, unexpected directions should prompt questions. Why? What is the efffect of following the directions? What is the effect of NOT following the directions? With HZSAIEOF I would definitely wonder what its effect is on other than Health Checker. snip (Semi-humorous post warning.) I have had nothing to do with Health Checker design or development and have never seen the code for nor heard anyone say exactly what HZSAIEOF does. So I can comment and speculate freely (grin), and maybe provide some context and maybe not since I've no clue what the program actually does. First off, I must note that IEFBR14 holds several records of dubious value. On our side, we have all read about how many APARs it's had, that it's likely that it might be one of very few modules whose size ever doubled as the result of an APAR and we have all (IBMers and everyone else) had any number of good laughs about the misadventures related this poor, humble module with its mere 2 lines of code (nowadays, anyway). On the other side, though, it's probably the most misused program we ever shipped to anyone in the entire history of MVS, OS/390, and z/OS. Yes, I said misused. Meant it, too. There! I feel better! Using IEFBR14 to allocate data sets is sort of like playing Russian roulette and betting you will always win. It might work out in your favor the very first time. It might not. Sooner or later, it won't. Unlike Russian roulette, though, a bad result will not be instantly apparent--and happily it won't be nearly as messy or permanent. 'BR14's return code will always be zero--that's what that, um, second instruction in it does--whether the jobstep for which it runs creates the data sets specified on DD statements or not, and whether they get cataloged or not. (No, we're not going to recode and retest all our samples and examples that use it to allocate data sets. It's too late for us to mend our ways in that regard, IBMers, customers, and vendors all, I suspect.) In addition to that, simple JCL allocation without an OPEN--this is what you get with 'BR14--does not write EOF for a new sequential DASD data set. From the very name of HZSAIEOF, and the penchant of good programmers to pick meaningful names when possible, I will speculate that it might perhaps, just maybe, stand for Allocate (data set) Indicating End-Of-File. You guys didn't see this? Need more coffee today...? Where's that Craddock guy when you need him, anyway? (Oh, no! Now I've done it. Next time they name a program like this, they'll probably use a random character generator. Or maybe they'll name it something misleading instead. If that isn't what happened this time, that is. And we're not telling.) But no matter what HZSAIEOF actually does do (and I ain't tellin' even if I do find out at some point), it's no surprise to me that someone would reasonably want you to use a program other than IEFBR14 to create a data set, just so you would know immediately if the operation failed and the data set would be in a known state for a program to process if the operation succeeded. And--honest!--nobody would have written a useless program, tested it, and shipped it just for fun. If the directions say you should use it, you should, even if you don't know why. At least, you should use it if you expect us to support you when there is a problem. Sometimes you've just got to trust us, at least this much. (Heck, when you think about it, you trust us with lots more than that, right?) OK, back to IBM-MAIN's regular programming. I dunno what got into me. I promise to be better from now on. ;-) -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
Hi John, (fun old story response to (Semi-humorous post warning.) post. And sometimes an 'exposure' is also a 'feature'. True story. a 'few' years ago we had a programmer who was a little shaky on disp coding, sometimes coding new,delete,catlg. Programmer had worked many years in a shop where the programmers did not do JCL. Sometimes there would be a special run with a clock time of 15-20 hours, and the most important output dataset coded - yeah, you guessed it :-) So, somebody, usually the programmer, would call me while the job was still running. I would mount the work pack private, and map the drive and remap every time the file took an extent. When the job when to good EOJ, and the file was deleted, I would absolute allocate each extent location with IEFBR14, concat in the extent order, output in one 'piece' and give it back to the programmer. Did that a number of times... On the other hand, there were the applications that allocated all files with IEFBR14 and then did not open the files unless the run was actually going to write to them. The next job in the run would expect to open that dataset, either empty or with application data. Surprise! Left over data! Those were 'fun'. Linda Mooney -- Original message -- From: John Eells ee...@us.ibm.com Patrick O'Keefe wrote: At the very least, unexpected directions should prompt questions. Why? What is the efffect of following the directions? What is the effect of NOT following the directions? With HZSAIEOF I would definitely wonder what its effect is on other than Health Checker. (Semi-humorous post warning.) I have had nothing to do with Health Checker design or development and have never seen the code for nor heard anyone say exactly what HZSAIEOF does. So I can comment and speculate freely (grin), and maybe provide some context and maybe not since I've no clue what the program actually does. First off, I must note that IEFBR14 holds several records of dubious value. On our side, we have all read about how many APARs it's had, that it's likely that it might be one of very few modules whose size ever doubled as the result of an APAR and we have all (IBMers and everyone else) had any number of good laughs about the misadventures related this poor, humble module with its mere 2 lines of code (nowadays, anyway). On the other side, though, it's probably the most misused program we ever shipped to anyone in the entire history of MVS, OS/390, and z/OS. Yes, I said misused. Meant it, too. There! I feel better! Using IEFBR14 to allocate data sets is sort of like playing Russian roulette and betting you will always win. It might work out in your favor the very first time. It might not. Sooner or later, it won't. Unlike Russian roulette, though, a bad result will not be instantly apparent--and happily it won't be nearly as messy or permanent. 'BR14's return code will always be zero--that's what that, um, second instruction in it does--whether the jobstep for which it runs creates the data sets specified on DD statements or not, and whether they get cataloged or not. (No, we're not going to recode and retest all our samples and examples that use it to allocate data sets. It's too late for us to mend our ways in that regard, IBMers, customers, and vendors all, I suspect.) In addition to that, simple JCL allocation without an OPEN--this is what you get with 'BR14--does not write EOF for a new sequential DASD data set. From the very name of HZSAIEOF, and the penchant of good programmers to pick meaningful names when possible, I will speculate that it might perhaps, just maybe, stand for Allocate (data set) Indicating End-Of-File. You guys didn't see this? Need more coffee today...? Where's that Craddock guy when you need him, anyway? (Oh, no! Now I've done it. Next time they name a program like this, they'll probably use a random character generator. Or maybe they'll name it something misleading instead. If that isn't what happened this time, that is. And we're not telling.) But no matter what HZSAIEOF actually does do (and I ain't tellin' even if I do find out at some point), it's no surprise to me that someone would reasonably want you to use a program other than IEFBR14 to create a data set, just so you would know immediately if the operation failed and the data set would be in a known state for a program to process if the operation succeeded. And--honest!--nobody would have written a useless program, tested it, and shipped it just for fun. If the directions say you should use it, you should, even if you don't know why. At least, you should use it if you expect us to support you when there is a problem. Sometimes you've just got to trust us, at least this much. (Heck, when you think about it, you trust us with lots more than that, right?) OK, back to
Re: Health Checker questions
Dave Danner wrote: On Tue, 9 Dec 2008 13:53:31 +0100, R.S. [EMAIL PROTECTED] it.COM.PL wrote: Peter Relson wrote: I can activate a check that was deactivated as well as I can undelete check that was deleted. That is not necessarily true. Well... This is want I wanted to learn more about. That's why I asked the question. When is the above untrue ? The only way to undelete a deleted REMOTE check would be to re-drive the check owner's HZSADDCK code. A lot of times that might be possible (or practical). From end-user point of view you delete check by P and undelete by E action character in SDSF. As simple as H for deactivate and A for activate. The manual does not explain the difference. The only topic related to check deletion is some explanation why the check can be undeleted automagically. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
I can activate a check that was deactivated as well as I can undelete check that was deleted. That is not necessarily true. When is the above untrue ? I choose not to answer fully. There is no reason that you should have to know this. My statement about the difference between deactivate and delete was clear. What leads you to believe that you can undelete something that has been deleted? It happens to be the case that for a lot of health checks, you can get the check re-added. Certainly that is not typical z/OS behavior across the board. The basic answer is: you cannot undelete a check if the adder of the check chooses not to re-add it. Adding of a check is done in many ways, including dynamic exit routines issuing HZSADDCK, programs running outside of HC issuing HZSADDCK, and parmlib specification accompanied by a modify command.. For the first, someone could choose to remove their dynamic exit routine after having done an add. This is not recommended, but there is no way to prevent it. For the second, the program might be written to stop processing if a delete has been seen. For the third, adding is up to you. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
On Wed, 10 Dec 2008 10:24:42 +0100, R.S. [EMAIL PROTECTED] wrote: From end-user point of view you delete check by P and undelete by E action character in SDSF. As simple as H for deactivate and A for activate. The manual does not explain the difference. The only topic related to check deletion is some explanation why the check can be undeleted automagically. That procedure only works for local checks that support delete/refresh. If you try it on a remote check - for example CHECK(IBMUSS,USS_PARMLIB) - the deleted check will not be 'undeleted' on a refresh (SDSF E). The Health Checker for z/OS Users Guide contains a lot of information about how checks are expected to react to different commands/circumstances. Bottom line: If you want to get rid of the check forever (or at least for the life of the IPL), use DELETE; if you just want to stop the check from running for awhile, use DEACTIVATE. Dave Danner CA, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
I can activate a check that was deactivated as well as I can undelete check that was deleted. That is not necessarily true. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
On Tue, 9 Dec 2008 13:53:31 +0100, R.S. [EMAIL PROTECTED] wrote: Peter Relson wrote: I can activate a check that was deactivated as well as I can undelete check that was deleted. That is not necessarily true. Well... This is want I wanted to learn more about. That's why I asked the question. When is the above untrue ? The only way to undelete a deleted REMOTE check would be to re-drive the check owner's HZSADDCK code. A lot of times that might be possible (or practical). Dave Danner CA, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Health Checker questions
Peter Relson wrote: Q: 1. HZSPDATA I allocated the dataset using HZSAIEOF program, however it seems to be empty. What does HZSAIEOF do? Can I use IEFBR14 instead? A: Are you opposed for some reason to following instructions? Please use what is provided. I will not answer either of the two questions aside from saying that HZSAIEOF makes the data set usable by HC. Maybe it does something more than IEFBR14 would do; maybe it does not. It is not surprising that the data set is empty when you allocate it. Once you have an HZSPDATA data set and run HC (for at least an hour) there will be data written to it. I did follow instructions. However I checked just formatted dataset and noticed it's empty! So I checked the job - just to preclude any chance of mistake. Then RTFM - no information like formatted dataset looks like empty, but it's not. Then asked the question above. I have no problem with following instructions, but sometimes I want to understand how does it work. Q: 2. Delete check vs deactivate check What is functional difference between delete check and deactivate check? A: You can't activate a check that has been deleted if you change your mind about wanting to run it. I dare to disagree. For me - user - this is not a difference. I can activate a check that was deactivated as well as I can undelete check that was deleted. The only difference is action character! H - deactivate A - Activate P - Delete E - Refresh (undelete) So, I RTFM, found no answer and asked on IBM-MAIN: what is the difference ? BTW: I just checked: I allocated empty HZSPDATA dataset with IEFBR14 and it works like HZSAIEOF-formatted one. It seems the ulitility above is dummy one, maybe reserved for future needs - or - I don't know what for. Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Health Checker questions
1. HZSPDATA I allocated the dataset using HZSAIEOF program, however it seems to be empty. What does HZSAIEOF do? Can I use IEFBR14 instead? 2. Delete check vs deactivate check What is functional difference between delete check and deactivate check? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.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.2008 r. kapitał zakładowy BRE Banku SA wynosi 118.642.672 złote i został w całości wpłacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
