Re: Free C Compiler
Timothy Sipples wrote: Thinking out loud some more, it seems much of the service could be done via convenient e-mail. Or perhaps you could use the already existing procedures with FTP, with the SITE JES option to submit and receive jobs. When the job is complete, you'll get another e-mail with a Web link to download the completed output (including binary). Or use the DIR command in FTP. And GET to receive the output. There might be a security step or two in here (such as registering your e-mail address first). H Any benefactors out there? Is this something a university might want to host, for example? I did once here of a large company that could probably manage it pretty easily. Probably just by providing an FTP address to one of it's already existing systems. The name of the company was ... let me see ... it started with an I. International ... Ummm . I know. Something to do with business, I think. Maybe Business Machines? IBM. Wonder if they could do that for us? How does it get any better than this? Clem - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- -- 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: DR and JES check point question
HI
Unless something has changed the IBM recommended JES ckpt config was one
on CF the other on disk and then to have the alternates visa versa so
that at start-up on the remote site, the cf structure would be empty but
the dasd ckt would have the data in a time consistent state ( xrc).
Regards
Gerard Ceruti
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Glenn Miller
Sent: 15 June 2007 11:13 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: DR and JES check point question
Hi Andy,
We use synchronous PPRC on a HDS9980V and synchronous SRDF on a EMC
DMX200 unit. We previously ( June 1998 to October 2004 ) had used XRC
to a
site about 900 'cable miles' away. One of the 'operational issues' we
had to
deal with was the fact that XRC being asynchronous might cause our D/R
solution to be seconds to possibly a minute or more 'behind' the 'write
activity'
of the production site. We didn't XRC the JES2 Checkpoint/Spool volumes
at
that time ( our PPRC/SRDF solution does now ) so that wasn't an issue.
The
thing I liked about XRC was the 'time consistency' of the data, even
across
multiple storage subsystems ( we had 4 HDS 7700E's, 1 HDS9960 & 1
HDS9980V ). So, XRC will make sure that the data is written to the XRC
Secondary DASD volumes in the same exact order they were written to the
XRC Primary DASD volumes. The question becomes: How does JES2 react
during startup when it attempts to access the primary CF resident
Checkpoint
dataset and that attempt fails? Have you tried that failure scenario at
your
primary site on a 'sandbox' z/OS system? For example, while JES2 is
running at
the primary site, SYSTEM RESET CLEAR the z/OS image AND SYSTEM RESET
CLEAR the CF LPAR that contains the primary checkpoint ( simulates a
site
failure at the primary site ). Then IPL z/OS and restart JES2, see what
messages/WTORs JES2 issues.
HTH
Glenn Miller
--
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
__
Standard Bank Disclaimer and Confidentiality Note
This e-mail, its attachments and any rights attaching hereto are, unless the
context clearly indicates otherwise, the property of Standard Bank Group Limited
and/or its subsidiaries ("the Group"). It is confidential, private and intended
for the addressee only. Should you not be the addressee and receive this e-mail
by
mistake, kindly notify the sender, and delete this e-mail, immediately and do
not disclose or use same in any manner whatsoever. Views and opinions
expressed in this e-mail are those of the sender unless clearly stated as those
of the Group. The Group accepts no liability whatsoever for any loss or
damages whatsoever and howsoever incurred, or suffered, resulting, or arising,
from the use of this email or its attachments. The Group does not warrant the
integrity
of this e-mail nor that it is free of errors, viruses, interception or
interference. Licensed divisions of the Standard Bank Group are authorised
financial services providers
in terms of the Financial Advisory and Intermediary Services Act, No 37 of 2002
(FAIS).
For information about the Standard Bank Group Limited visit our website
http://www.standardbank.co.za
___
--
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: DR and JES check point question
Glenn Miller wrote: Hi Andy, [...] The thing I liked about XRC was the 'time consistency' of the data, even across multiple storage subsystems ( we had 4 HDS 7700E's, 1 HDS9960 & 1 HDS9980V ). So, XRC will make sure that the data is written to the XRC Secondary DASD volumes in the same exact order they were written to the XRC Primary DASD volumes. Data consistency is *mandatory* feature of remote copy, otherwise such a copy is simply unusable and then piece of junk. Lost money. *Each* remote copy solution should assure data consistency, although XRC assures it in "easy way", "automatically". And don't forger about data consistency BTW: Did I mention data consistency ? The question becomes: How does JES2 react during startup when it attempts to access the primary CF resident Checkpoint dataset and that attempt fails? Checkpoint reconfiguration dialog will appear on console. Deep sh*t if it is HMC SYSCON - in that case is good to remember how it is look like. Have you tried that failure scenario at your primary site on a 'sandbox' z/OS system? > For example, while JES2 is running at the primary site, SYSTEM RESET CLEAR the z/OS image AND SYSTEM RESET CLEAR the CF LPAR that contains the primary checkpoint ( simulates a site failure at the primary site ). Then IPL z/OS and restart JES2, see what messages/WTORs JES2 issues. I would also suugest INJERROR utility designed to destroy CF structures by name. BTW: Such solutions have to be tested regardless of checkpoint configuration and remote copy technique. 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: Multiple TSO logons (was: Patents, ...)
Paul Gilmartin wrote: > On Thu, 14 Jun 2007 20:30:43 -0500, Tony Harminc wrote: >> I've looked at this, and "it isn't pretty" doesn't even begin to describe >> it. Unless IBM has severely modularized things since the last non-OCO >> version of this stuff, it is full of hardcoded knowledge of not only VTAM >> (and TCAM!) module names, but of their various quirky behaviours. >> > So how does IKJEFT01 in batch bypass all that stuff? How does it bridge > the userid==address space name pitfall? > > -- gil Some of the things that rely on userid=jobname probably include inter-ASID TPUT (incl. OS SEND command) and LOGON RECONNECT. If you are not fussed about those two things (and anything else that I should have listed) then it is "easy" to allow a single TSO-authorised userid to logon to TSO multiple times concurrently on a single "MVS" image. (Stroking chin for flashback sequence...) It all began because for years I wanted the RACF user name (of up to 20 characters) to be placed into the programmer name field of the JOB card of the TSO session's JCL. I complained about this somewhere - maybe even here - and whined about a RACF deficiency when compared to ACF2 which does do this. Walt the RACF wizard kindly pointed out that this is not up to RACF to do but TSO. So, whipping up a TSO Logon Post-Prompt Exit (IKJEFLD3) from the sample, the RACF user name went into the JOB card. Nice. Now, for my next trick, I change IKJEFLD3 to fiddle the job name by adding a character after the TSO userid (which has a max length of 7 chars) to form the new job name. This allows up to 40 TSO user address spaces from the one id (blank or "TSO classic", 26 alphabetic, 10 numeric, and 3 national). Oh, and of course the other thing to handle is the SYSIKJUA ENQ on the userid. This is deftly dealt with by cunningly converting these ENQs to shared (instead of exclusive) - achieved by a simple front-end to SVC 56. Warning: the way I did it makes no allowance for SYSPLEX or shared SPOOL (Didn't JES2 enforce unique TSU job ids in a MAS? Was this ever changed?) because the decision of which suffix character to use for the job name is made by scanning the address space names in the virtual storage of *this* system only. It all seemed to work okay but it was OS/390 and not the most heavily-loaded system in the world (although I still think it would work on z/OS and I don't think system load affects it's viability). And as I say, the ability to LOGON RECONNECT goes out the window, which may not be an issue if you use session manager software or have a reliable network. And as far the ISPF profile data set, we settled on a scheme where the session's profile data set (perhaps userid.jobname.ISPPROF) was cloned from the user's original or base profile data set by the logon CLIST. It may have even been deleted and cloned anew each time so that updates to the base profile got promulgated. And I may have even written a function which returned the current job name into a CLIST variable. The method is described in member MULTITSO of CBT file 134. The JCL and source code for the TSO exit and the SVC 56 front-end and its loader are also present in other members of that file. And that was about six and a half years ago... (stops stroking chin). Cheers, Greg P. -- 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: Patents, Copyrights, Profits, Flex and Hercules
Phil Payne wrote: > Then there was Nestle Frankfurt, who wanted both CPUs to have the same serial > number. > > BS3000 was pulled because Fujitsu (deservedly) lost a court case. One of the > settlement > conditions was the withdrawal of BS3000, another was $600 million, if memory > serves. At the > time, I not only expected it but felt it long overdue. Served 'em right. > AIM was an affront > to IBM. I'll bite. Of all the things that could be an affront to IBM, why did you pick AIM? AIM - Advanced Information Manager - was the DBMS Fj developed for their own OS (X8) and then ported to their MVS clone (F4). IIRC it was a network data base, not heirarchical like IMS, not relational like DB2 (although later there was an AIM-RDB), and so probably not copied from anything IBMish at all. Unless you do mean AIM-RDB, which I wouldn't know if it was DB2-like or not. Just wondering... Greg P. -- 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: Multiple TSO logons (was: Patents, ...)
>Didn't JES2 enforce unique TSU job ids in a MAS? Was this ever changed? This was changed around OS/390 2.7. And, I have exploited it on a z/OS 1.4 & 1.7 system. I wrote an article that has a sample EXEC to allow you to invoke multiple sign-ons, but there is one point that is incorrect (you can only sign on once per image). 10) November 2006: "Digging Into the Bag of ISPF Tricks" http://tinyurl.com/yyghzr The execs mentioned in the article are also on the CBT Tape. - 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: Patents, Copyrights, Profits, Flex and Hercules
Phil Payne wrote: Then there was Nestle Frankfurt, who wanted both CPUs to have the same serial number. BS3000 was pulled because Fujitsu (deservedly) lost a court case. One of the settlement conditions was the withdrawal of BS3000, another was $600 million, if memory serves. At the time, I not only expected it but felt it long overdue. Served 'em right. AIM was an affront to IBM. The Fujitsu machines were very good. I keep seeing this Hercules [EMAIL PROTECTED] turning up, and [EMAIL PROTECTED] it is. For the nthousandth time - it ain't EVER going to happen - there are so many things against it there's no time to list them. It wasn't going to happen before the IBM/PSI thing (for a number of reasons, one being the attitude of the owners) and IBM actually said so at the time: "IBM has taken a business decision not to license its software on this platform." IBM chooses with whom it sleeps. And after IBM/PSI - Jeez! I wish we could save the bandwidth. It is, I think, quite simple. If there is not a low cost platform or method to develop software for the MVS part of Z/OS, it might as well be dead. And Linux on Z/OS will be what is left. And, if that is what people choose, fine. But we need to know that that is what is happening. And IBM needs to be aware. And this talk of software being developed in garages seems to me that Apple and Microsoft started that way? And "IBM has taken a business decision not to license its software on this platform.". Business is based on restricting information. Making things scarce so they will cost more. Patenting seeds, for example. So they can suddenly become "commercial". Adding terminator genes so that you have to buy a special product from Monsanto to grow seeds that once were freely available! So, IBM makes a business decision that small users are to be phased out. Fine. Where do you think they are going to go, for heavens sake? What happened when OS/2 was phased/forced out? We are all being forced into the *nix and/or Microsoft camp. OK. Let's admit it, and go with the flow But let's be very clear who is doing the pushing. IBM. You can say that it is IBM's choice. It is. And they have made it. (And that the shareholder's profits have to be protected.) Ce la vie to Z/OS. By restricting access, and not making Z/OS as easy to use as it could be. (That GUI for SPF could have been so much better, with just a tiny bit of effort.) Clem -- 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: Patents, Copyrights, Profits, Flex and Hercules
> I'll bite. Of all the things that could be an affront to IBM, why did you > pick AIM? AIM - Advanced Information Manager - was the DBMS Fj developed for their > own OS (X8) and then ported to their MVS clone (F4). > > IIRC it was a network data base, not heirarchical like IMS, not relational > like DB2 (although later there was an AIM-RDB), and so probably not copied from anything > IBMish at all. > > Unless you do mean AIM-RDB, which I wouldn't know if it was DB2-like or > not. AIM-RDB was indeed "DB2-like" at least from a programming point of view, but it was a lot less functionally rich, which made the "A" in AIM a little ironic. At the time a lot of the FJ product names were prefixed with "A". It's fair to say AIM itself was IMS-ish. I worked for some time as a consultant for FJ at FAI Insurance doing a conversion/migration from the AIM database to AIM-RDB. It was an incredibly painful exercise, not least because there was no real data integrity in either DBMS. The application had to provide data integrity with application logic. You can just imagine how well that went, so a major part of the effort was spent in cleaning up and reconciling all of the dangling references and dead data in the original AIM database. The other part was solving a severe deadlock problem in AIM-RDB. I wrote some software to do deadlock detection and analysis. FJ snarfed it up and added it to their own product without so much as a by-your-leave. That work was later immortalized in the reference to "RYO ALC mods stuffed into the Bamboo OS" in an infamous Ken Dubbo post. CC -- 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: Multiple TSO logons (was: Patents, ...)
Paul Prejudice[1] is like a neglected slip, it sometimes shows to the acute embarrassment of the wearer. There was not an iota of "VTAM jargon" present in the quoted post - but there were some very well-known CICS abbreviations. Were these the supposed "VTAM jargon"? I even went to the Google archive to check since it appeared I must have missed a post. As others indicate below - but without highlighting the actionable and completely unfounded slur on VTAM - whatever the perceived problem here is, VTAM is as innocent as a new-born babe. VTAM has no interest whatsoever in userids and DD-names or whatever is standing in the way of the subject under discussion. Thus "getting rid of VTAM" is utterly irrelevant. "Feelings" and "suspicions" are bad mentors when tying to steer technical discussions. Chris Mason [1] Since religion has been introduced, the word "bigotry" also comes to mind. But there's always hope, look at Ulster - or - as some say - "the six counties". - Original Message - From: "Paul Gilmartin" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Wednesday, June 13, 2007 9:03 PM Subject: Re: Multiple TSO logons (was: Patents, ...) On Wed, 13 Jun 2007 13:48:19 -0400, Kirk Talman wrote: More accurately, single ID, single LPAR, single application, multiple session facility. I stand corrected. Thanks. That is an application issue. E.g., we have two TORs using a single AOR/FOR pair. For some transactions we disallowed using both AORs at the same time in the transaction's security signon part because the transaction was not sophisticated enough to build temp storage queue names to distinguish simultaneous signins (and related issues). And it was deemed not worth the effort to correct that. Theology. Dogma. Simply to start doing it right, you must stop doing it wrong. Somehow I feel a major culprit is VTAM because whenever this issue arises an expert starts spouting VTAM jargon. Get rid of VTAM; let TCP/IP connect directly to the TMP input/output data streams. For TSO and whatever TCAS is called now, the issue becomes having the address space name created be different from the userid. What would that break? To have the session manager handle that wrinkle using e.g. morphing the userid used at signon and then having the security system or application handle the authorization via unmorphing the userid is messy. btdtgt-scars. Somehow this all works for batch EXEC PGM=IKJEFT01, which I am told is the same TMP. Seems like a solved problem. I suspect it only works because there's no VTAM in the way. -- gil -- 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: Multiple TSO logons (was: Patents, ...)
Tony So in tune with Paul's verbal abuse, mixing metaphors, he should be casting his boulders in the direction of TSO, not VTAM since it would appear the TSO developers have been negligent in not keeping strictly to the published TCAM and VTAM APIs. Apart from the minimal intervention "around the edges" which the exceptional function supplied by VTAM in order to have local (non-SNA) channel-attached 3270 controllers (or their "look-alikes") appear to be type 0 secondary logical units which only incidentally use the 3270 data stream, VTAM has no interest in the *content* of the 3270 data stream. The "minimal intervention" extends only to a mapping and transformation of the first character in the data stream, the "write control character", to the "channel command word" and vice versa in order to ensure that the 3270 data stream is the same in all environments fore the benefit of the device-independent program. Or something like that, it's a while since I looked at it but I know that whatever VTAM did can't have been one of your inhibitors. Incidentally, did you ever take a look at the 3270<>Asynchronous ASCII protocol converters such as the 3708 or 7171? Chris Mason - Original Message - From: "Tony Harminc" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Friday, June 15, 2007 3:30 AM Subject: Re: Multiple TSO logons (was: Patents, ...) On Wed, 13 Jun 2007 14:03:15 -0500, Paul Gilmartin <[EMAIL PROTECTED]> wrote: Theology. Dogma. Simply to start doing it right, you must stop doing it wrong. Somehow I feel a major culprit is VTAM because whenever this issue arises an expert starts spouting VTAM jargon. Get rid of VTAM; let TCP/IP connect directly to the TMP input/output data streams. I've looked at this, and "it isn't pretty" doesn't even begin to describe it. Unless IBM has severely modularized things since the last non-OCO version of this stuff, it is full of hardcoded knowledge of not only VTAM (and TCAM!) module names, but of their various quirky behaviours. This is one of those situations where everyone agrees that it would be a Good Thing to replace some part of the legacy stuff, but everyone disagrees on just which parts are legacy junk, and which are the very core of the architecture. When I worked for Amdahl/Antares on Huron, we had complete control over the applications that drove 3270 screens, and once all the real green-screens had gone away, it began to make sense to consider designing our own new 3270 protocol along with an emulator that would exploit it. But it never happened, because there were just too many layers (CICS, VTAM, TSO, ...) that all had to be fixed at exactly the same time. Tony H. -- 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: Multiple TSO logons
Tom There's some confused thinking here which I can't quite put my finger on. As John McKown has indicated, there is a very simple way that the otelnetd server creates an environment which allows, in effect, line-mode TSO commands. If the proposed "z/OS System Explorer" is what I think it is - judging from the use of the Microsoft "Explorer" word - it approaches the file handling which may be compared to what the *TSO extension* ISPF does. In other words, what "z/OS System Explorer" replaces is ISPF. "z/OS System Explorer" exploits some lower level environment in the client platform which may be equated to 3270 data stream analysis and construction in the server platform in the case of ISPF sitting on top of TSO. In other words it's rather tricky to draw parallels even if the end-user is performing much the same functions with the proposed "z/OS System Explorer" as with ISPF. I'm not sure "remov(ing) the need for VTAM in the middle of things" is much of a key distinction to mention compared to all the other necessary changes. Chris Mason - Original Message - From: "Tom Moulder" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Friday, June 15, 2007 3:11 PM Subject: Re: Multiple TSO logons Craddock, Chris wrote: Nope. Completely different. The z/OS System Explorer was/is a single address space server that provided a (Java) GUI interface for most of the things you would typically do under ISPF and SDSF. File browse/edit (using your own choice of editor), search/compare, dataset manipulation, job submission, job output management yada yada yada. And there were plans for a set of product functions that would plug into the same infrastructure and UI. CC Agreed Chris. I did not say that it was a replacement for TSO. It did however remove the need for VTAM in the middle of things because it was JAVA and pure TCP/IP. Tom -- 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: Multiple TSO logons
Chris On the contrary, I would regard SUB=MSTR to be anything but bizarre and rather more the normal way of things than having to bother with a complicated "subsystem" environment. It's only when your program does exceptional things such as needing, say, a SYSIN file that a spooling subsystem becomes useful. Probably I got this attitude by having to wrestle with system startup automation where, for example, the NetView SSI task and an "automation" NetView task needed to be started at an early stage with SUB=MSTR so that they could manage the starting of address spaces such as, well, JES2. Indeed the address space management also extended to managing shutdown - although logging off the VM userid supporting the MVS image was equally effective and a bit faster! - and exchanging one JES2 environment for another. In case this last operation looks odd it's important to know these were student environments for hands-on classes. I also had a few trivial VTAM-based programs which performed functions such as presenting the round-trip time for 1920 or so characters to a 3270 display which didn't need JES2 and so were quite happy to be started SUB=MSTR. Chris Mason - Original Message - From: "Craddock, Chris" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Friday, June 15, 2007 4:54 PM Subject: Re: Multiple TSO logons Tom Moulder said of the z/OS System Explorer Agreed Chris. I did not say that it was a replacement for TSO. It did however remove the need for VTAM in the middle of things because it was JAVA and pure TCP/IP. True. And in one of those bizarre "who'da thunkit?" moments, it also turns out that it will cheerfully run SUB=MSTR. So you can do a bunch of stuff without even JES being up - basically anything that does not in and of itself require the services of the JES. Obviously you would have to do some quirky things in your z/OS setup to do that, but I tried it out and it worked. BTW> there's an embedded gen-u-wine Apache web server running inside of it - which is how I happen to know how much of a pain in the butt it is to port the native Apache C code onto z/OS. CC -- 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: Multiple TSO logons
Chris Mason wrote: Tom There's some confused thinking here which I can't quite put my finger on. As John McKown has indicated, there is a very simple way that the otelnetd server creates an environment which allows, in effect, line-mode TSO commands. If the proposed "z/OS System Explorer" is what I think it is - judging from the use of the Microsoft "Explorer" word - it approaches the file handling which may be compared to what the *TSO extension* ISPF does. In other words, what "z/OS System Explorer" replaces is ISPF. "z/OS System Explorer" exploits some lower level environment in the client platform which may be equated to 3270 data stream analysis and construction in the server platform in the case of ISPF sitting on top of TSO. In other words it's rather tricky to draw parallels even if the end-user is performing much the same functions with the proposed "z/OS System Explorer" as with ISPF. I'm not sure "remov(ing) the need for VTAM in the middle of things" is much of a key distinction to mention compared to all the other necessary changes. Chris Mason Chris, I'm not any kind of a network guy. But I've worked with WD/z and its z/OS System Explorer. It seems to use APPC / APPN. How does that tie to VTAM / TCP/IP / TN3270? Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- 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: Multiple TSO logons
Steve If "WD/z and its z/OS System Explorer" can use APPC/APPN it almost certainly means that they have chosen to use the logical unit (LU) type 6.2 API[1] as, possibly just one of, the means to exchange data between, I am assuming, a "server" environment and a "client" environment. This would mean only that the underlying "transport" was SNA and it could be old, legacy subarea SNA as easily as bright shiny new APPN or indeed, the intermediate Low Entry Networking (LEN) - or any combination thereof. Given that SNA and actually specifically APPN is used, it means that one of the logical SNA links between the assumed "server" and "client" can be an IP network[2] supported by RFC 2353, a set of protocols originally offered by IBM using the name "Enterprise Extender" (EE). Making the assumptions I have about "WD/z and its z/OS System Explorer", I can't see that TN3270 will be in any way involved. I'm now going to take a look at http://www-05.ibm.com/il/news/events/mf/downloads/03-Productive-Developer-Tools.pdf - after the chore I have been instructed to perform - so I may be back later with some clarifications. Chris Mason [1] They may have chosen specifically to limit their choice of API to that defined by "Common Programming Interface for Communications" (CPI-C), a formal "standard" for SNA-based communication. [2] *Not* using "TCP" as the "transport" over the IP network since EE uses "UDP" as the "transport". - Original Message - From: "Steve Comstock" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Saturday, June 16, 2007 5:31 PM Subject: Re: Multiple TSO logons Chris Mason wrote: Tom There's some confused thinking here which I can't quite put my finger on. As John McKown has indicated, there is a very simple way that the otelnetd server creates an environment which allows, in effect, line-mode TSO commands. If the proposed "z/OS System Explorer" is what I think it is - judging from the use of the Microsoft "Explorer" word - it approaches the file handling which may be compared to what the *TSO extension* ISPF does. In other words, what "z/OS System Explorer" replaces is ISPF. "z/OS System Explorer" exploits some lower level environment in the client platform which may be equated to 3270 data stream analysis and construction in the server platform in the case of ISPF sitting on top of TSO. In other words it's rather tricky to draw parallels even if the end-user is performing much the same functions with the proposed "z/OS System Explorer" as with ISPF. I'm not sure "remov(ing) the need for VTAM in the middle of things" is much of a key distinction to mention compared to all the other necessary changes. Chris Mason Chris, I'm not any kind of a network guy. But I've worked with WD/z and its z/OS System Explorer. It seems to use APPC / APPN. How does that tie to VTAM / TCP/IP / TN3270? Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- 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: Multiple TSO logons
Steve What a mess! I suspect you saw APPC and assumed APPN - a false assumption I very strongly suspect. I found a "IBM WebSphere Developer for zSeries Prerequisites", SC31-6352-05, document and the nearest it got to suggesting VTAM was required was the "IP Services component of IBM Communications Server" which rather clearly indicates that VTAM, the *SNA* Services component of IBM Communications Server, is *not* required. It did, however, rather oddly, mention APPC - and also ISPF. This, by the way, is what prompted the "what a mess" or perhaps "dog's dinner". I also found ""IBM WebSphere Developer for System z Version 7.0, APPC and WebSphere Developer for System z", SC23-5885-00. I'm guessing this document has been put together as a way of explaining how to set up APPC, note specifically APPC/MVS, because it is wanted for one of the "under-the-covers" functions purely *within* z/OS. I believe the "under-the-covers" function is "WEBSPHERE DEVELOPER - TSO COMMANDS SERVICE - THIS FORMAT DISPLAYS RESULTS OF ISPEXEC AND NATIVE TSO COMMANDS" as I found in the comments of one of the "server" jobs. Moreover, the reason for ISPF is in order to support setting up the APPC/MVS environment - and maybe the environment of some other z/OS products. It's all a while ago for me now but I believe I managed to set up my APPC/MVS environment purely with batch jobs so I *think* ISPF is really optional for APPC/MVS. So, it looks like the communication between z/OS and the Windows PC is purely IP. I got a hint that maybe TN3270 was also used from that presentation. You'd better work through the manuals to be sure. If you need some help with the APPC/MVS side, I did keep some examples of my playing with APPC/MVS long ago and the SC23-5885-00 manual reminded me rather precisely of those samples I kept. So do let me know if necessary. Chris Mason - Original Message - From: "Steve Comstock" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Saturday, June 16, 2007 5:31 PM Subject: Re: Multiple TSO logons ... Chris, I'm not any kind of a network guy. But I've worked with WD/z and its z/OS System Explorer. It seems to use APPC / APPN. How does that tie to VTAM / TCP/IP / TN3270? Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- 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: Multiple TSO logons
Chris Mason wrote: Steve What a mess! I suspect you saw APPC and assumed APPN - a false assumption I very strongly suspect. Yes. I saw APPC and thought there might also be an APPN piece to this. I found a "IBM WebSphere Developer for zSeries Prerequisites", SC31-6352-05, document and the nearest it got to suggesting VTAM was required was the "IP Services component of IBM Communications Server" which rather clearly indicates that VTAM, the *SNA* Services component of IBM Communications Server, is *not* required. It did, however, rather oddly, mention APPC - and also ISPF. This, by the way, is what prompted the "what a mess" or perhaps "dog's dinner". I also found ""IBM WebSphere Developer for System z Version 7.0, APPC and WebSphere Developer for System z", SC23-5885-00. I'm guessing this document has been put together as a way of explaining how to set up APPC, note specifically APPC/MVS, because it is wanted for one of the "under-the-covers" functions purely *within* z/OS. I believe the "under-the-covers" function is "WEBSPHERE DEVELOPER - TSO COMMANDS SERVICE - THIS FORMAT DISPLAYS RESULTS OF ISPEXEC AND NATIVE TSO COMMANDS" as I found in the comments of one of the "server" jobs. Moreover, the reason for ISPF is in order to support setting up the APPC/MVS environment - and maybe the environment of some other z/OS products. It's all a while ago for me now but I believe I managed to set up my APPC/MVS environment purely with batch jobs so I *think* ISPF is really optional for APPC/MVS. So, it looks like the communication between z/OS and the Windows PC is purely IP. I got a hint that maybe TN3270 was also used from that presentation. You'd better work through the manuals to be sure. That makes sense with what I observe. If you need some help with the APPC/MVS side, I did keep some examples of my playing with APPC/MVS long ago and the SC23-5885-00 manual reminded me rather precisely of those samples I kept. So do let me know if necessary. No. I'm working with it OK. I just thought it was interesting how they do this and was a little curious what it meant was going on under the covers. Chris Mason Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- 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: Multiple TSO logons
Chris Mason said (to Tom Moulder) > > If the proposed "z/OS System Explorer" is what I think it is - There's nothing "proposed" about it. The product exists already. It is possible that something with a similar name exists elsewhere, but Tom and I were referring to a BMC product. I know a little about it since it was my idea and my team that wrote it. > judging from the use of the Microsoft "Explorer" word - it approaches the file handling > which may be compared to what the *TSO extension* ISPF does. > In other words, what "z/OS System Explorer" replaces is ISPF. Yes and no. It is by design very similar in function. But "replace" implies more than was perhaps intended. It does not attempt to replace user or vendor written ISPF application functionality. It is web server based rather than ISPF dialog manager based, so while there is (or could be) functional equivalence, it isn't really a direct replacement. It provides a more sophisticated (and familiar) point and click GUI interface for the main functions people typically use ISPF and SDSF for. The explorer GUI is easier for less expert people to use than ISPF. It runs as a JAVA app on the user's workstation and behaves exactly as you would expect a Windows or UNIX desktop application to work. And if you're familiar with the Windows File Manager, then you already know what it looks like and how to use it. > "z/OS System Explorer" exploits some lower level environment in the client platform > which may be equated to 3270 data stream analysis and construction in the server > platform in the case of ISPF sitting on top of TSO. Well this particular z/OS explorer is contains an embedded Apache web server. You point your favorite web browser at the URL and away it goes. All of the client UI interaction flows over HTTP. > In other words it's rather tricky to draw parallels even if the end-user > is performing much the same functions with the proposed "z/OS System > Explorer" as with ISPF. Yes. It is functionally similar and probably easier for most people, but not the same thing. No flames please, I know there are ISPF experts out there, I may even qualify for that term myself :-) We were trying to address the question of what do you do when your new generation of users reel back in horror when you ask them to logon to TSO? Even the ISPF cognoscenti would probably agree that newbies find it a rather user-vicious environment compared to what they are used to. > I'm not sure "remov(ing) the need for VTAM in the middle of things" is > much > of a key distinction to mention compared to all the other necessary > changes. True. OTOH it would have been absurdly difficult to accomplish the same thing using VTAM. Possible certainly, but not worth the effort. CC -- 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: Multiple TSO logons
Chris Mason said > I would regard SUB=MSTR to be anything but bizarre and > rather more the normal way of things than having to bother with a > complicated "subsystem" environment. It's only when your program does > exceptional things such as needing, say, a SYSIN file that a spooling > subsystem becomes useful. > > Probably I got this attitude by having to wrestle with system startup > automation where, for example, the NetView SSI task and an "automation" > NetView task needed to be started at an early stage with SUB=MSTR so that > they could manage the starting of address spaces such as, well, JES2. Yeah I agree. I'm an infrastructure guy. Most of my own code has always run SUB=MSTR to support automation so that the automation product can start right after master scheduler and then drive the rest of the start-up sequence. And of course, it has to be able to hang around after JES goes during shutdown for much the same reason. However SUB=JES is the default and most of the code you would typically run on a z/OS image runs under the JES subsystem whether it needs to or not. From an ISV point of view it is quite common to get customer push-back when you run things under MSTR because they either don't understand what that really means, or they assume you're up to no good. "Oh well". CC -- 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
CICS AEXZ abend outage for zOS 1.8/Top Secret 9.0 users.
Anyone else experienced this problem? Our CICS regions have been down since 6 AM CDT Saturday due to AEXZ abend in CEMT. This was reported to IBM who referred us to CA. CA confirmed the problem and provided maintenance to Top Secret. We've rolled back to TS 8.0 as an interim for some of our systems that were still zOS 1.6. Several additional companies in addition to us have reported the same problem. No golf today. -- 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: CICS AEXZ abend outage for zOS 1.8/Top Secret 9.0 users.
Yes, We are one of the 'lucky' ones to experience this first hand. It took awhile to find out what the problem was, as we saw no TSSx messages pointing to the error, just an AEXZ abend. IBM gave us the direction towards CA. I spoke with the technical support manager for CA-Top Secret and he told me what the issue was; There is a storage overlay in the date field area with a 'C1'. If we did nothing, Top Secret would work fine tomorrow as the date area in error, only affected today's date. I told him I needed the fix as soon as it gets out of the 'test' phase, today. Still waiting Claude Richbourg Florida Department of Corrections Systems Programmer III 850-921-1383 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Saul Babonas Sent: Saturday, June 16, 2007 4:47 PM To: IBM-MAIN@BAMA.UA.EDU Subject: CICS AEXZ abend outage for zOS 1.8/Top Secret 9.0 users. Anyone else experienced this problem? Our CICS regions have been down since 6 AM CDT Saturday due to AEXZ abend in CEMT. This was reported to IBM who referred us to CA. CA confirmed the problem and provided maintenance to Top Secret. We've rolled back to TS 8.0 as an interim for some of our systems that were still zOS 1.6. Several additional companies in addition to us have reported the same problem. No golf today. -- 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 -- 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: CICS AEXZ abend outage for zOS 1.8/Top Secret 9.0 users.
IBM has put out a flash, 1264171, describing the problem and its current status. We backed out TSS 9.0 a few hours ago; fortunately it was in development only. -- 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: CICS AEXZ abend outage for zOS 1.8/Top Secret 9.0 users.
We have the same problem, CA QO89178 fixed the problem -- 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: CICS AEXZ abend outage for zOS 1.8/Top Secret 9.0 users.
We used this zap to circumvent the problem: NAME CAKSSIGN CAKSSIGN VER 056E 4780,B5C6 REP 056E 4700 -- 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: Patents, Copyrights, Profits, Flex and Hercules
Ed Gould wrote: On Jun 14, 2007, at 8:51 PM, FRASER, Brian wrote: I don't think CA was the original developer. What mainframe software did CA originally develop? My vague recollection was the cobol optimizer capex. I could be wrong its been ages and ages. - IIRC, CAPEX was the company name. The first CA product I remember was CA-Sort, around 1976. -- 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: Multiple TSO logons
On Sat, 2007-06-16 at 16:46 -0400, Craddock, Chris wrote: > From an ISV point of view it is quite common to get customer > push-back when you run things under MSTR because they either don't > understand what that really means, or they assume you're up to no good. CC is of course correct - customers should be smart enough to know it has nothing at all to do with running SUB=MSTR. ISV are *always* up to no good ... :0) Shane ... -- 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: Multiple TSO logons
> >However SUB=JES is the default and most of the code you would typically >run on a z/OS image runs under the JES subsystem whether it needs to or >not. From an ISV point of view it is quite common to get customer >push-back when you run things under MSTR because they either don't >understand what that really means, or they assume you're up to no good. >"Oh well". > Or the system programmer has to justify the behaviour to an auditor and the vendor did not provide an easily understood explanation of why SUB=MSTR or an IEFSSNxx entry is required. At that point they push back. I worked in one shop where pages of documentation had to be provided before certain parmlib members could be updated. And not just make it APF, but what specifically needs to be APF. In that case it is not what I can understand, but what the auditor can understand from the vendor supplied documentation. not my interpretation. -- 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: Patents, Copyrights, Profits, Flex and Hercules
On Jun 16, 2007, at 5:26 PM, Rick Fochtman wrote: Ed Gould wrote: On Jun 14, 2007, at 8:51 PM, FRASER, Brian wrote: I don't think CA was the original developer. What mainframe software did CA originally develop? My vague recollection was the cobol optimizer capex. I could be wrong its been ages and ages. - IIRC, CAPEX was the company name. The first CA product I remember was CA-Sort, around 1976. Yes I remember casort we looked at it (along with syncsort and maybe 1 other) in that time frame. I think we selected Syncsort as (besides IBM's sort) was the only one that supported E61. I was trying to scrap the barnacles off my memory chips and decided I couldn't reliably say one way or the other but for some reason CApex kept coming to the forefront. I did not write the proposal for CAPEX so I don't remember. I know it was proposed to stave off an upgrade to the 4341's we had. As you probably remember the company I worked for was extremely stingy with the $$. I had to write a proposal just for TSO. I was livid when it got bounced back to me as I used the British spelling of a word. I had it retyped and re-proofed in 2 hours and handed back to the VP as he was leaving for the day. He was mad at me for having him missing his train. I personally took it over to the CEO's office and dropped it off with his assistant. The assistant was so surprised that it got back to him it less than a day, I think he thought we were just going to go away. He had no idea how wrong he was. 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: FTPing a z/OS file into the z/OS UNIX HFS results in wrong translation
Josef Berger wrote: how we can FTPing a z/OS file (code Page IBM-1141) into the z/OS UNIX HFS (code Page IBM-1047) with correct translation ?.. if using TYPE E with Mode B and SITE SBD=(IBM-1141,IBM-1047) no translation was in effect. if using TYPE A the target data on z/OS UNIX HFS was translated to ASCII. ISO8859-1,. in both cases the SITE SBD=(IBM-1141,IBM-1047) had no effect. any advice how FTPing a MVS file to a z/OS UNIX HFS file with correct translation to code page IBM-1047 would be very appreciated. Have you tried using OCOPY locally and coping the file to a HFS and then ftp'ing it to the remote system? Does the remote site have the required translate tables? Have you tried "locsite SBD=(IBM-1141,IBM-1047)" or coding it in your FTPDATA parameters for this transfer? -- 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: Multiple TSO logons
CC Did you ever want to take something back after you have done it? What I would give to recall the message that started this whole thing. So hard to explain. Offline to you would have had more meaning. Tom Moulder Chris Mason said (to Tom Moulder) > > If the proposed "z/OS System Explorer" is what I think it is - There's nothing "proposed" about it. The product exists already. It is possible that something with a similar name exists elsewhere, but Tom and I were referring to a BMC product. I know a little about it since it was my idea and my team that wrote it. > judging from the use of the Microsoft "Explorer" word - it approaches the file handling > which may be compared to what the *TSO extension* ISPF does. > In other words, what "z/OS System Explorer" replaces is ISPF. Yes and no. It is by design very similar in function. But "replace" implies more than was perhaps intended. It does not attempt to replace user or vendor written ISPF application functionality. It is web server based rather than ISPF dialog manager based, so while there is (or could be) functional equivalence, it isn't really a direct replacement. It provides a more sophisticated (and familiar) point and click GUI interface for the main functions people typically use ISPF and SDSF for. The explorer GUI is easier for less expert people to use than ISPF. It runs as a JAVA app on the user's workstation and behaves exactly as you would expect a Windows or UNIX desktop application to work. And if you're familiar with the Windows File Manager, then you already know what it looks like and how to use it. > "z/OS System Explorer" exploits some lower level environment in the client platform > which may be equated to 3270 data stream analysis and construction in the server > platform in the case of ISPF sitting on top of TSO. Well this particular z/OS explorer is contains an embedded Apache web server. You point your favorite web browser at the URL and away it goes. All of the client UI interaction flows over HTTP. > In other words it's rather tricky to draw parallels even if the end-user > is performing much the same functions with the proposed "z/OS System > Explorer" as with ISPF. Yes. It is functionally similar and probably easier for most people, but not the same thing. No flames please, I know there are ISPF experts out there, I may even qualify for that term myself :-) We were trying to address the question of what do you do when your new generation of users reel back in horror when you ask them to logon to TSO? Even the ISPF cognoscenti would probably agree that newbies find it a rather user-vicious environment compared to what they are used to. > I'm not sure "remov(ing) the need for VTAM in the middle of things" is > much > of a key distinction to mention compared to all the other necessary > changes. True. OTOH it would have been absurdly difficult to accomplish the same thing using VTAM. Possible certainly, but not worth the effort. CC No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.8.17/850 - Release Date: 6/15/2007 11:31 AM -- 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: Multiple TSO logons
Ken Tomiak said > <<>>Or the system programmer has to justify the behaviour to an auditor and > the vendor did not provide an easily understood explanation of why SUB=MSTR or > an IEFSSNxx entry is required. That pretty much makes my point. If they don't understand what either of those things mean, then any number of pages explaining why it's necessary are going to be essentially worthless. Ask me how I know :-( I also find it depressingly ironic that customers (righteously) require us to play by the rules of the architecture and operating system and then go all whiny and crybaby on us when doing the aforementioned "right thing" means they have to make a one line change in a parmlib member. You would think we were asking them to consign first born children into slavery. And being treated like a giant doofus who's just aching to knock down western civilization along the way just puts frosting on the cake. My tolerance for calm rational exposition goes downhill very quickly in those situations. And having done that same job myself a good many years earlier, I have a lot of trouble mustering any sympathy for their position. I tend to believe that having the keys to the family Buick ought to signify the holder is at least knowledgeable enough to get the key in the thing and be able to back it out the driveway without having the owner's manual and a "Buick Controls for Dummies" book open on the front seat. Draw any analogy you want to other systems programmers (or auditors) that you have known over the years. Of course none of this august body would ever fall into that group though right? CC -- 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: Patents, Copyrights, Profits, Flex and Hercules
Clem Clarke <[EMAIL PROTECTED]> wrote: >If there is not a low cost platform or method to develop software for >the MVS part of Z/OS, it might as well be dead. And Linux on Z/OS will >be what is left. Let's make this clear once and for all: THERE IS NO LINUX ON Z/OS. Not now, not ever. There is USS and there is Linux on z. They're as different as z/OS and VSE (in fact, in some ways that's not a bad analogy -- they're sorta kinda similar but distinct, and run on the same hardware). If you meant USS, fine; if you meant Linux on z, fine; but don't say "Linux on z/OS". It devalues your entire thesis, which is a shame, 'cause you make some excellent points. ...phsiii (cranky after midnight) -- 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
