Re: [spam] Open z/Architecture or Not
Veilleux, Jon L wrote: Bob Shannon wrote: Some, such as logical swap, were incorporated into MVS. Others, such as the dual master catalog mod at a large US insurance company, proved to be a nightmare to maintain and an even worse nightmare to remove. AMEN Bob. Although usermods did have their up side, especially the catalog mod. It gave a relatively new Systems Programmer a LOT of experience coding assembler and reading standalone dumps...before IPCS..ouch Open code does *NOT* mean open for update. Of course if you want, you can modify it, but then it is *your* code, and you are expected to support it. Ergo, the rules, what is allowed for customer to modify, and what is locked could remain the same as in OCO. BTW: I'm not open code enthusiast. I understand problems of IP rights when the code is disclosed (wasn't it a beginning of MSP system ?). However the more documentation/description/functional diagrams/PoPs/etc the more it helps users. One of methods is to provide sources. Just my $0.02 -- 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.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: [spam] Open z/Architecture or Not
Radoslaw Skorupka said: Open code does *NOT* mean open for update. Of course if you want, you can modify it, but then it is *your* code, and you are expected to support it. Ergo, the rules, what is allowed for customer to modify, and what is locked could remain the same as in OCO. The issue as I see it is that if the source is available it WILL be modified. It seems to be a common trait of computer geeks that they just have to tweak things to make them better(?). The problem comes when you want to upgrade. Having to refit those mods, especially when the original creator is no longer employed at your institution, can be time consuming and expensive. On the other hand, some of the MVS mods were necessary and have since been incorporated into the OS or have made some folks a lot of money as vendor products (MIM, PDSE (the product not the dataset format), etc). Also, most of the good system programmers that I know learned a lot of their skills due to these modifications and the need to dig into the source code, not to mention the vast pool of debuggers that were available. I remember when we could open a problem with IBM and many times give them a possible solution to the problem at the same time. With OCO that is no longer possible. Just my $.02 worth. Jon Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: [spam] Open z/Architecture or Not
On Dec 6, 2007, at 1:46 PM, Bob Shannon wrote: I grant you that untrammeled access to source code _can_ result in disasters. Any example ? Sure. The thousands of in-stream usermods that were written prior to XA, and which greatly inhibited subsequent upgrades. I certainly agree that in the early days usermods were written to overcome functional deficiencies in MVS. Some, such as logical swap, were incorporated into MVS. Others, such as the dual master catalog mod at a large US insurance company, proved to be a nightmare to maintain and an even worse nightmare to remove. Incidentally, that particular company had approximately 200 instream usermods. Consider the effort it would take to roll out z/ OS releases with that level of modification even if source code were available. Bob, I somewhat agree with you. In addition you probably should further say that usermods can be simple or complex. Just because you have a usermod does not necessarily add to the implementation time (all that much). While I agree some mods can do so (like the ones you suggested) there are others that only marginally add to implementation time. One shop I had approximately 100 usermods to apply after the tapes were d/l'd and installed. The 100 usermods took roughly 1 day to install. These were small mods like compiler options etc, all standard IBM type mods. I had exits which required maybe 2 days of additional time (most of that time were JES2 exits) that had to be looked at because of macro/exit changes. I maintained a reasonably cleaned system. I also refused to install any OEM package that made changes to the OP SYS, I also refused to install any package that hooked into the OS or front ended any IBM module. I think the last sentence is the most important as those generally take the longest IMO. Ed -- 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: [spam] Open z/Architecture or Not
Phil Payne wrote: Belated birthday greetings. Hmm. I grant you that untrammeled access to source code _can_ result in disasters. Any example ? OK, I'am aware of one: Wide open code could mean more holes/errors disclosed. It also could mean more errors FIXED. Not to mention more suggestions to enhance it. What's better ? -- 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.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- 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: [spam] Open z/Architecture or Not
On Thu, 6 Dec 2007 20:23:21 +0100, R.S. wrote: Phil Payne wrote: I grant you that untrammeled access to source code _can_ result in disasters. Any example ? I think the key words in Phil's post are untrammeled and can. He went on to describe the benefits. -- Tom Marchant -- 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: [spam] Open z/Architecture or Not
I grant you that untrammeled access to source code _can_ result in disasters. Any example ? Sure. The thousands of in-stream usermods that were written prior to XA, and which greatly inhibited subsequent upgrades. I certainly agree that in the early days usermods were written to overcome functional deficiencies in MVS. Some, such as logical swap, were incorporated into MVS. Others, such as the dual master catalog mod at a large US insurance company, proved to be a nightmare to maintain and an even worse nightmare to remove. Incidentally, that particular company had approximately 200 instream usermods. Consider the effort it would take to roll out z/OS releases with that level of modification even if source code were available. Bob Shannon Rocket Software -- 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: [spam] Open z/Architecture or Not
On 6 Dec 2007 11:23:52 -0800, [EMAIL PROTECTED] (R.S.) wrote: I grant you that untrammeled access to source code _can_ result in disasters. Any example ? OK, I'am aware of one: Wide open code could mean more holes/errors disclosed. It also could mean more errors FIXED. Not to mention more suggestions to enhance it. What's better ? P.R. disasters? -- 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: [spam] Open z/Architecture or Not
Bob Shannon wrote: Some, such as logical swap, were incorporated into MVS. Others, such as the dual master catalog mod at a large US insurance company, proved to be a nightmare to maintain and an even worse nightmare to remove. AMEN Bob. Although usermods did have their up side, especially the catalog mod. It gave a relatively new Systems Programmer a LOT of experience coding assembler and reading standalone dumps...before IPCS..ouch Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: [spam] Open z/Architecture or Not
In a message dated 12/6/2007 1:23:55 P.M. Central Standard Time, [EMAIL PROTECTED] writes: OK, I'am aware of one: Wide open code could mean more holes/errors disclosed. It also could mean more errors FIXED. Not to mention more suggestions to enhance it. What's better ? Back when the OCO battle was really hot it was reported at SHARE that one of the biggest pushers for OCO were some of the Change teams that had seen the increase in user code and mods grow more than linearly. I know one of the hardest bugs I ever shot was a JES3 hickey that was clobbering itself only to find out we were running a 'Common' VM mod that trampled a little on some of the DIAG code. **Check out AOL's list of 2007's hottest products. (http://money.aol.com/special/hot-products-2007?NCID=aoltop000301) -- 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
