> The marketing team were horrified. "We can't sell > this to our customers, it would be a HUGE > conversion effort for them and they will revolt and > buy someone else's systems!"
I believe it; what I don't believe is that they actually had a clue as to the actual conversion effort. With a decent CI and RCI it could have gone quite smoothly. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Farley, Peter x23353 <peter.far...@broadridge.com> Sent: Monday, March 30, 2020 7:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARM= vs PARMDD= and symbol substitution That was an interesting and probably true VSAM story, or at least very easy to believe true. I had a similar exposure to the "original" VSAM design from a lecturer in an "Operating Systems and Design" course I took at a local technical college. The lecturer was, IIRC, an IBM Fellow (or had once been one). He claimed that the original VSAM design was farmed out to a team of computer science theorists who presented a design for what they named "Access Method 1" back to IBM. It would have completely replaced ALL other access methods in the OS/MVS world with a single access method for all types of files. The marketing team were horrified. "We can't sell this to our customers, it would be a HUGE conversion effort for them and they will revolt and buy someone else's systems!" The lecturer then told us that the head of the marketing team reportedly took home the AM1 design, blue-penciled out all the sophisticated parts and brought back the result as what he called "Access Method Zero". The lecturer claimed that the resulting AM0 document is VSAM as it was originally released. Perhaps apocryphal, but it made sense to me at the time. Typical Blue thinking of the age (mid-to-late 1970's I think). Peter -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Tony Thigpen Sent: Monday, March 30, 2020 6:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PARM= vs PARMDD= and symbol substitution As I said, there are some good things and bad things for each OS. As to your question, if someone is using the file when the 5 hour job gets to that point, then it just waits. Deadly embrace is normally a function of poor design or bad scheduling. When that happens we just beat our programmers so they don't do it again. :-) But, if it is something that might happen, we just convert the VSAM file to shareoption-4, which *WORKS* in z/VSE by letting multiple programs update the VSAM file at the same time without any special programming by the programmer. Unlike z/OS which never implemented shareoption-4 as documented in the original design document. (I had a conversation with a IBM guy that worked on the original VSAM code for MVS(?) when he was at IBM. He said that they just ran out of time getting it to work, so they changed the document so that it was the programmers responsibility to lock/unlock, not the OS. The OS handled it the lock/unlock/wait in DOS/VS). He tried to get them to do it right later, but powers that be said it was out and could no longer be changed.) Tony Thigpen Charles Mills wrote on 3/30/20 6:00 PM: > Not beating up on VSE. ("My OS is better than your OS.") DOS/360 was my first > IBM OS. > > But the negative -- what OS/360 was trying to avoid -- is deadly embrace. > What if that 5-hour job gets up to the end and then CANNOT allocate the VSAM > file? And worst case, what if the program that owns it is waiting on > something the 5-hour job already owns? > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Tony Thigpen > Sent: Monday, March 30, 2020 8:38 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PARM= vs PARMDD= and symbol substitution > > Yes, before the EXEC card. > > Actually, there is no 'allocation' of a file by z/VSE during the JCL > processing. The file is only 'allocated' once it is opened and > 'unalocated' once the program closes the file. > > For instance, if you have a 5 hour program, that just needs to update > a 'totals' VSAM file at the end of the 5 hours, as long as the program > does not open the file until it needs the file, any other program can > use, including updating, the file until that time. > > So, basically, you 'own' the file only while you have it opened. > > One ramification is that you can't create a file simply by having in > the jcl, like in z/OS. You have to open it to create it. > > Tony Thigpen > > Paul Gilmartin wrote on 3/30/20 11:05 AM: >> On Mon, 30 Mar 2020 10:11:53 -0400, Tony Thigpen wrote: >> >>> Coming from the z/VSE world, some of the JCL stuff in z/OS just is 'weird'. >>> >> I understand that in z/VSE tne DD statementw precede the EXEC for the >> step. Intuitive because allocation is done first. >> >>> 1) In z/VSE, the conditional jcl statements are more logical, not >>> something akin to RPN. >>> 2) Our SETPARMs are sequential. You can have multiple SETPARMs of >>> the same variable in the same step and intervening statements are >>> processed using the 'then value' of the SETPARM. >>> 3) We can modify and even define SETPARM values via programs as a >>> way to pass information between steps. >>> >>> Don't get me wrong, there are good things in both, but sometimes >>> issues with the underlying basics of each lead to strange 'higher level' >>> items. >>> >>> Working daily on z/VSE, z/VM and z/OS really get's confusing sometimes. >>> Even simple things like responding to a console message. z/VSE needs >>> the outstanding message number, followed by a space, then the >>> response. Yet, z/OS usually needs a comma where z/VSE had the space, but >>> not always. >> >> -- gil -- 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
