Can I tell whether a site is Linux on z
Is there a way I can tell if http://bahn.hafas.de is Linux on z. If it is that says interesting things about whether z series might be able to handle google. The site does timetable lookup, trip planning, etc. and apparently is among the best for planning European trips. -- 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
Problem with ibm-main rejecting valid postings
I am getting postings rejected because I am not authorized (I get bounced e-mail message) yet they are accepted when I resend them without change. Is anyone else seeing this problem? Clark Morris -- 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
Semi-OT: problem with Windows XP Service Pack 3
A month or so ago I applied Service Pack 3 to Windowns XP home from a download and started getting a message that Automatic Updates was turned off. I tried to change the Automatic Updates setting but it was locked (all of the choice button were greyed out). I think I got the message that I didn't have the authority which was peculiar since I was logged on to the account with administrator privileges. This was annoying but since I normally apply the updates and don't use automatic update, I ignored the problem hoping a subsequent update would cure it. On Wednesday, I downloaded and tried to apply the latest upgrade to Zone Alarm Internet Security Suite which normally is a very simple exercise. The upgrade didn't work because I did not have the administrator privilege for installing the True Vector component. After making various attempts and checking the Zone Alarm site, I went to the Microsoft site. There I found that for at least some people Service Pack 3 fouls up some entries in the registry and there is a fix. I have an e-mail into Microsoft right now verifying that the fix only restores full administrator privileges to the administrator logons and not the user logons and that the download program mentioned also works on XP home as well as PRO. I suspect the simplest way to tell whether you have the problem is to logon on to an account with administrator privileges and try to change the Automatic Updates setting. If you can't change it, DON'T try to install any systems software (Microsoft updates seem to work) like Zone Alarm. Go to www.microsoft.com and from support go to the page for Service Pack 3. You will find that there is free e-mail, chat AND toll-free free support in North America for Service Pack 3 issues. Apparently there have been a number of them. Before we in the mainframe environment feel completely smug, there are PTF's and hiper alerts for a reason. While I haven't read about anything like the DF/EF catalog problems that I heard about or DFP PE chain problems that I experienced, no vendor is free of major glitches. Given that Microsoft fixes and updates for home users are to be installed by people who are not system programmers or systems administrators, it is in a sense amazing to me that the process works as well as it does. I might add that I read the KB letters for all of the fixes I apply and have found them useful in understanding why I am putting on the fix. I'm sending this because for many of us, Windows XP is the operating system of choice or affliction. -- 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
(fwd) Re: Java is becoming the new Cobol
Pete Dashwood who is the author of most of this posting, has coded for the mainframe and CICS. Unfortunately, based on the actual actions of the COBOL standards committee, the lack of 64 bit support or support for even parts of the 2002 COBOL standard that were in specific SHARE requirements, and other things that I and others have kvetched about regarding mainframes and COBOL over the years, I tend to agree with Pete though not necessarily for his reasons. Clark Morris On Thu, 3 Jan 2008 11:17:49 +1300, in comp.lang.cobol "Pete Dashwood" <[EMAIL PROTECTED]> wrote: > > >"tlmfru" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> Or will COBOL become the new mainframe? I seem to recall that mainframes >> were pronounced dead a couple of decades ago. >> >> PL > >Mainframes ARE dead in terms of doing anything interesting with them :-) > >The best chance of survival they have is by attachment to the Network and >welcoming the Web. To the extent that they do this and become powerful >servers in a Network environment, they will have a future. The days when >they sat at the centre of things and controlled everything are long gone. To >that extent, the role they served decades ago is gone, so they ARE dead as >far as that goes. > >Don't hold your breath for a resurgence of COBOL, in the role which it >served decades ago, either. > >Fortress COBOL is in ruins. It has been sacked and looted. Whatever was of >value has been incorporated into the Brave New World and the barbarians on >their wiry little ponies have swept on... > >Pete. >-- >"I used to write COBOL...now I can do anything." > -- 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
Graphics is reason mainframe is losing was (fwd) Re: Java is becoming the new Cobol
The following on comp.lang.cobol should give us some food for thought although the mainframe is now being used as a web server. Clark Morris On Sat, 05 Jan 2008 11:22:26 -0600, in comp.lang.cobol Scott <[EMAIL PROTECTED]> wrote: >Howard Brazee <[EMAIL PROTECTED]> wrote in >news:[EMAIL PROTECTED]: > >> It's about allowing a student to connect his laptop computer to the >> Web, log on, and sign up for a class. It's about allowing a salesman >> to connect his laptop computer to the Web, enter his sales and pull up >> some graphs. >> >> The functionality is more than just the pretty face. > > >It is about a pretty face WITH functionality and you cannot have >a pretty face on the mainframe. Companies always want the pretty screens >and the mainframe loses because of it, in spite of its clear advantage in >almost every other area. > >I'm sorry to say but as a Systems Analyst, over and over again, users >and management are always more interested in how an application LOOKS >than in how it WORKS. Of course if it doesn't work right there is a big >problem. But the point is, in every phase of an application life cycle, >to the people outside of I.T. who hold the purse strings, LOOKING good >is always their first priority. And to THEM, looking good MEANS >functionality. That's what screws the mainframe. > >It may have cost IBM a pretty penny years ago to make graphic screens >but what is it costing them now? Short-sighted corporate mentality >loses the business again. -- 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: Purge all members from a PDSE
On 8 Jan 2008 05:12:03 -0800, in bit.listserv.ibm-main you wrote: >I thought the same thing. What exactly *do* PDSEs bring to the table that >PDSs didn't have or doesn't do? They do bring a number of good things like large load modules, the theoretical ability for longer than 8 character names and the ability to move forward. They also bring the IDIOTIC idea that a library DOES NOT need to be accessible at IPL time and that access can be interrupted by a started task abend. This carries on the tradition started by not being able to use locally attached SNA 3270's as consoles because locally attached SNA 3270's were only usable through the started VTAM task. Clark Morris > >David Logan > >-Original Message- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf >Of Van Dalsen, Herbie >Sent: Tuesday, January 08, 2008 5:53 AM >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: Purge all members from a PDSE > >Edward Jaffe wrote: >>> DEL SYS1.PDSE >>> ALLOCATE SYS1.PDSE > >Old habits die hard... I thought that the whole purpose of PDSE's was low >maintenance... No more IEBCOPY compress jobs, No more delete/re-alloc jobs ? >If this thing(not a sand fairy but a PDSE) is happy to continue forever >without compression etc... why reverting to the old methods... Download the >CBT and be content... Less fragmentation on the disk if you aren't >continuously deleting and reallocating... > >Herbie > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf >Of R.S. >Sent: 08 Januarie 2008 12:15 nm >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: Purge all members from a PDSE > >Edward Jaffe wrote: >> R.S. wrote: >>> By command ? >>> >>> I'd suggest IDCAMS: >>> DEL SYS1.PDSE >>> ALLOCATE SYS1.PDSE >>> >>> Also works with PDSes. >>> :-) >> >> The problem with this or JCL re-allocation is the high potential for >> getting something wrong. Wrong attributes, wrong space, wrong placement, >> etc., the inability to perform the function with an outstanding DISP=SHR >> ENQ in effect, and the unfortunate effect on the data set creation date >> saved in the DSCB. > >ENQ is the reason. I get it. >However IMHO reallocation risk is not a risk in well managed environment. >I absolutely disagree with Wayne's point about UPDATE. User should have >sufficient authorities. What would you do with READ access? I would ask >for more. UPDATE is insufficient to compress PDS. Should I search for >another method of compress or simly request for ALTER? >My $0.02 > >BTW: I would suggest looking at Smart DFSORT Tricks. AFAIR it contains >trick for deleteting all members using DFSORT and IDCAMS. > > > >-- >Radoslaw Skorupka >Lodz, Poland -- 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: Migration from Mainframe to othre platforms - the othe bell?
On 31 Jan 2008 11:10:53 -0800, in bit.listserv.ibm-main you wrote: >I have seen several shops get or try to get off the mainframe. The biggest >reason the upper management gives for trying to get off the mainframe is >no one coming out of college knows anything about the mainframe. When I >was hired as a SYSPROG I had never seen a mainframe the company gave some >test and asked if I wanted to learn the mainframe and I said yes. I was >trained by older SYSPROGs. I am sure that is how most SYSPROGs got trained >by their mentors. >I have never seen a mainframe to whatever platform happen in budget or in >the time frame that was sold to them. I have seen companies chunk millions >at trying to get off of the mainframe when they could train the staff and >exploit the mainframe for all of uses for decades. >The 4 shops I know off personally that did or tried to get off the >mainframe were all drive by upper management lack of understanding of the >mainframe or a sales rep that came in told them they could get off the >mainframe in 6 months and save them millions of dollars. What happened was >what they said the cost would be multiply it by 20 to get close and if >that does not drive the company into bankruptcy the added cost for all the >floor space for all the servers, office space for all the additional staff >to manage the server farms, and lets not forget all the extra cost of the >software for every server and and every engine turned on on the server >will unless they have a endless money pot. > >In the end I have never heard of any shop getting off of the mainframe and >saving money. I don't know maybe there is savings after one or two hundred >years. > While I don;t know if they saved any money, I worked at a shop that had gone from the mainframe to HP-UX and was running a mainframe like environment including an ISPF for Unix and CICS for Unix. All VSAM was moved to Oracle as was the true database type info. I don't think they had more than 3 HP-UX boxes. > > >From: >"Kelman, Tom" <[EMAIL PROTECTED]> >To: >IBM-MAIN@BAMA.UA.EDU >Date: >01/31/2008 12:16 PM >Subject: >Re: Migration from Mainframe to othre platforms - the othe bell? > > > >Are you interested in just z/OS stories or in stories about mainframe >Linux also? One big story back in 2006 was the one about Nationwide >Insurance moving the processing from 400 servers to 2 IBM z900 Linux >systems. At the time they estimate the savings to by $15 million over 3 >years. Here is one article on it or you can Google "nationwide linux" >to get some more. > >http://www.linux.com/feature/59984 > > > >Tom Kelman >Commerce Bank of Kansas City >(816) 760-7632 >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On >> Behalf Of Mautalen Juan Guillermo >> Sent: Thursday, January 31, 2008 7:58 AM >> To: IBM-MAIN@BAMA.UA.EDU >> Subject: Migration from Mainframe to othre platforms - the othe bell? >> >> Hi, >> >> I am full of reports, sent to Management, about completely succesfull >> conversions from the "old and expensive" "IBM Mainframe to other >> platforms. And, as you may know, the most important argument is that >the >> Mainframe is very expensive and the same level of processing, with the >> same degree of thrust, can be achieved in other platforms with much >less >> money. Of course, i dont beleive this, or at least i dont think things >> to be so simple. So, i want to collect some information to support the >> Mainframe side. >> >> Are there somewhere on the web, as a counterpart of all the marketing >> flood about getting rid of the Mainframe, stories, reports or analysis >> of : >> >> - Conversions (or Consolidations) from other platforms into >Mainframes. >> - Stories of unsuccessful migrations from Mainframe to other >platforms. >> - Serious and independant cost analysis between different solutions. >> - Serious and independant studies comparing the security level of the >> different platforms. >> >> >> Thanks in advance for your help, >> >> >> Juan G. Mautalen >> >> >> >> El contenido del presente mensaje y sus anexos es privado, >confidencial y >> de exclusivo uso para el titular de la direccion de correo electronico >a >> quien esta dirigido. Puede contener informacion privilegiada o >amparada >> por el secreto profesional o por disposiciones legales y/o >reglamentarias >> vigentes. Cualquier modificacion, retransmision, diseminacion o >> divulgacion de su informacion se encuentra expresamente prohibida y su >uso >> inadecuado puede derivar en responsabilidad civil para el usuario o >> configurar los delitos previstos en los articulos 153 a 157 del Codigo >> Penal. Si no fuere uno de los destinatarios consignados o lo hubiere >> recibido por error, Ud. NO ESTA AUTORIZADO a utilizar total o >> parcialmente, copiar, enviar, revelar, imprimir, divulgar de manera >alguna >> el contenido del presente mensaje o el de sus adjuntos. En >consecuencia, >> tenga a bien comunicarsel
Re: RSV-XCEL Going Away
On 7 Feb 2008 14:51:15 -0800, in bit.listserv.ibm-main you wrote: >Hi, > >AOS works fine instead of RSVF for us. >You can open a PMR or better just ask Level-2 to test this with you the >next time you have a PMR active for something else. The IBM folks may >enjoy the practice too some don't use it too often. > >Only gotcha I have seen is you can get a pop-up challenging you for the >required authentication information and if you don't pay attention and >miss it or just try to start over you can get all hung up. Watch for a >prompt if you are behind a Web Proxy and make sure you know what format >to key in your userid or domain\userid and password. You can supply the >proxy information in a file if needed. I have not bothered or had as I >don't use it very often so I just key it in. > >Here is a quote from a skeptical co-worker after he tried AOS and liked >it better than expected. > >Start quote - >I recently set up a session in AOS with a friend of mine from IBM CICS >level II and it worked like a champ! > >He was able to do ANYTHING on our system, including read my EMAIL if he >wanted to. What are the security implications of this? How easy would it be for a hacker to get into this? If the level 2 guy could read the e-mail, he could read confidential data bases. > >CICS, TSO, Web USER INTERFACE,OUTLOOK, WORD etc., anything that is on >our desktop, just like remote screen viewing or dialing to our PC from >home. > >We had a few kinks to iron out BEFORE we got to that point however. > > >And then I saw A.O.S., >Now I'm a believer, >There's not a trace, >Of doubt in my mind! > >Here is a link to the procedure the CICS team will use to start a >session with IBM. > >I STRONGLY suggest everyone get someone from IBM on the line and step >through the process, before we have a PROD problem, like I did. >End quote -- > >We have written procedures (hey we have procedures for everything...) > >Procedure to work online with IBM support using Assist On-site Process >(AOS) > >June 5, 2007 > > >AOS is a product from Tivoli much like Net meeting. >IBM can share the keyboard to go ANYWHERE on our GEICO systems. >TSO, WEB USER INTERFACE, CICS, OUTLOOK, you name it.. > >1) Create a member on your C drive in NOTEPAD with the following >name and one line entry: >a. Name: proxy_ibm.txt >b. Content: Proxy=xxPPROXY.x.xxx:80 <--- your companies proxy >2) Go to the following Link with IBM on the phone: > http://www-1.ibm.com/support/assistonsite/form1.html >3) You need our IBM site number xxx-. <--- your companies IBM >site# >4) You need a valid PMR-Branch-Country code. >5) IBM will give you the connection code. >6) Select the "I Agree" button >7) You will be prompted to download and run a browser plugin >ibmaos.exe. The download may be blocked by your browser. To get around >this select the "click here" option to download the file. >8) When the download is complete, select RUN. >9) You will be prompted for a Proxy Authentication. This is your >RACF userid and password. >10)They're in! > > > >Bottom line AOS works and is even better than RSVF since we can share >out access to all our tools including those that don't have a 3270 >interface. > >Best Regards, > >Sam Knutson, GEICO >System z Performance and Availability Management >mailto:[EMAIL PROTECTED] >(office) 301.986.3574 > >"Think big, act bold, start simple, grow fast..." > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On >Behalf Of Larre Shiller >Sent: Thursday, February 07, 2008 5:33 PM >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: RSV-XCEL Going Away > >Mark - > >I have not had to use this in an emergency, but I have tested this: > >http://www-1.ibm.com/support/assistonsite/form1.html > >And is seemed to work just fine. > >Larre Shiller >US Social Security Administration > >This email/fax message is for the sole use of the intended >recipient(s) and may contain confidential and privileged information. >Any unauthorized review, use, disclosure or distribution of this >email/fax is prohibited. If you are not the intended recipient, please >destroy all paper and electronic copies of the original message. > >-- >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: Execution job class restriction
On 14 Mar 2008 09:25:06 -0700, in bit.listserv.ibm-main you wrote: >On 14 Mar 2008 06:28:28 -0700, in bit.listserv.ibm-main >(Message-ID:<[EMAIL PROTECTED]>) >[EMAIL PROTECTED] (Tom Russell) wrote: > >>>Is there a way to restrict jobs from running it a >>>particular job class? >>Is >>>there >>>more than one way and if so, what is the easiest? TIA >> >>I did this with IEFUJI, as it prevents users from changing >>the jobclass after it has been submitted. > > So, a user submits a job in a 3rd-shift class and >goes home. 3rd shift starts, and the job abends because >he's not authorized for that class. > > I prefer an immediate check and notification. An >exit in SDSF takes care of most user attempts at changing >jobclass. I'd rather let any other attempts go through >than have the above scenario which punishes an honest >mistake. My solution in 1988 was to set the job class in exit 6 based on time, the number of tape drives (up to 3), the TCAM queue requested if any and type of user. If the system knows what job class is allowed, I felt the system should set it and not bother the user with one more thing to remember. I believe the exit is in file 432, Philips Mods on the CBT tape. Clark Morris -- 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
(fwd) Re: Is IT becoming extinct?
This probably was cross-posted to both comp.lang.cobol and bit.listserv.ibm-main. Pete Dashwood is a long time consultant who has CICS and COBOL experience. I don't necessarily agree with him but he does have many good insights. Clark Morris On Tue, 25 Mar 2008 13:54:55 +1300, in bit.listserv.ibm-main "Pete Dashwood" <[EMAIL PROTECTED]> wrote: > > ><[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> http://blogs.zdnet.com/projectfailures/?p=666 >> >> (Not from where I'm standing - but I might not be standing the right >> place) > >I have been saying similar things for some time. > >The arrogance of IT alienated it from the rest of the organization... > >(I believe this was a major factor in the demise of COBOL; users just got >pissed of with being treated like crap and grabbed any alternate solutions >(packages, outsourcing, SaaS) as soon as they became available. Added to >this, you have a rising generation who are much more computer literate than >their parents were and are quite cappable of devising their own (albeit, >"imperfect and disintegrated" from an IT perspective) solutions with >spreadsheets and databases. The resulting chaos is what we're seeing today. >Getting a hold on this and integrating disparate IT operations throughout >the company so that a coherent picture can be derived is a large part of >what some IT departments are doing. This represents a shift in IT away from >technical service and into management of information. the role of the >Technocrats is being ever diminished.) > >The split between the Business and IT has always been a contrived one. Agile >methodologies recognise this and are successfully (re-)combining the two. > >Is IT becoming extinct? Depends what you mean by "IT"... > >I don't think IT is becoming extinct (yet...) but the need for businesses to >develop in-house IT applications is definitely under threat. There are many >alternatives and some companies are getting really good value from dropping >their IT departments. It is MUCH cheaper to simply buy the service than to >do it yourself. > >In-house IT development is expensive (prohibitively so if you insist on >using procedural languages like COBOL with line-by-line hand carved >solutions...embedding your business into millions of lines of archaic >geek-code), and nobody likes the IT department anyway... they consistently >treat people who are not technical with condescension and arrogance and are >not exactly warm and friendly when you need an IT service. Their track >record is abysmal, and most of the organisation would be very glad to see >the back of them. Why would you go to IT. cap in hand, when the new students >in your department can knock you up a desktop solution in a day or so that >is exactly what you need? > >The role of the in-house IT department to develop and provide services will >definitely be taken out of the corporate environment and relegated to a >handful of software companies. > >Long term, the Nirvana is for people to interact with, and utilise the power >of, computers, without requiring specialist knowledge or interfaces or >go-betweens (like the Priests of COBOL). When this is attained (and it is >still a fair way off, although steps are made towards it every year...) THEN >you could say IT was extinct. > >Meantime, there are ASPECTS of IT which certainly are becoming, or even have >become extinct. > >Have you heard anyone discussing "EDP" recently? > >Pete. >-- >"I used to write COBOL...now I can do anything." > -- 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: Is IT becoming extinct?
On Tue, 25 Mar 2008 11:41:29 -0700 (PDT), in bit.listserv.ibm-main you wrote: > > >Pete Dashwood wrote: >> <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> > http://blogs.zdnet.com/projectfailures/?p=666 >> > >> > (Not from where I'm standing - but I might not be standing the right >> > place) >> >> I have been saying similar things for some time. >> >> The arrogance of IT alienated it from the rest of the organization... >> >> (I believe this was a major factor in the demise of COBOL; users just got >> pissed of with being treated like crap and grabbed any alternate solutions >> (packages, outsourcing, SaaS) as soon as they became available. Added to >> this, you have a rising generation who are much more computer literate than >> their parents were and are quite cappable of devising their own (albeit, >> "imperfect and disintegrated" from an IT perspective) solutions with >> spreadsheets and databases. The resulting chaos is what we're seeing today. >> Getting a hold on this and integrating disparate IT operations throughout >> the company so that a coherent picture can be derived is a large part of >> what some IT departments are doing. This represents a shift in IT away from >> technical service and into management of information. the role of the >> Technocrats is being ever diminished.) >> >> The split between the Business and IT has always been a contrived one. Agile >> methodologies recognise this and are successfully (re-)combining the two. >> >> Is IT becoming extinct? Depends what you mean by "IT"... >> >> I don't think IT is becoming extinct (yet...) but the need for businesses to >> develop in-house IT applications is definitely under threat. There are many >> alternatives and some companies are getting really good value from dropping >> their IT departments. It is MUCH cheaper to simply buy the service than to >> do it yourself. >> >> In-house IT development is expensive (prohibitively so if you insist on >> using procedural languages like COBOL with line-by-line hand carved >> solutions...embedding your business into millions of lines of archaic >> geek-code), and nobody likes the IT department anyway... they consistently >> treat people who are not technical with condescension and arrogance and are >> not exactly warm and friendly when you need an IT service. Their track >> record is abysmal, and most of the organisation would be very glad to see >> the back of them. Why would you go to IT. cap in hand, when the new students >> in your department can knock you up a desktop solution in a day or so that >> is exactly what you need? >> >> The role of the in-house IT department to develop and provide services will >> definitely be taken out of the corporate environment and relegated to a >> handful of software companies. >> >> Long term, the Nirvana is for people to interact with, and utilise the power >> of, computers, without requiring specialist knowledge or interfaces or >> go-betweens (like the Priests of COBOL). When this is attained (and it is >> still a fair way off, although steps are made towards it every year...) THEN >> you could say IT was extinct. >> >> Meantime, there are ASPECTS of IT which certainly are becoming, or even have >> become extinct. >> >> Have you heard anyone discussing "EDP" recently? >> >> Pete. >> -- >> "I used to write COBOL...now I can do anything." > >The demise of Cobol, eh? > >Odd then, that the estimated value of Cobol code currently in >production is over $10,000,000,000,000. That's TRILLION. That estimate may be vastly overstated. A large number of in-house COBOL systems and packages written in COBOL have been replace by things like SAP. Many companies change from the mainframe because the package they believe will best run the business doesn't run on the mainframe and the reliability of box x using operating system y is good enough. Is Peoplesoft (now from Oracle) still in COBOL? Does Oracle's language still generate COBOL? > >And I'm not a Cobol coder, I code in a FAR more civilized language, >Rexx. > >Mickey Clark Morris -- 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: Free Up Unowned CSA/ECSA
On 5 Sep 2007 05:46:05 -0700, in bit.listserv.ibm-main you wrote:
>
>I fully agree with the sentiment that you should not take it upon yourself
>to free common storage that someone else obtained unless you (somehow) are
>able to know 100% that it is not used. And I fully agree that "unowned"
>does not mean "unused".
>
>Let me go a bit further, however, since "unowned" is not a category that
>the system has chosen to delineate.
>The categories that VSM supports are:
>owner=system
>owner=some-active-space identified at time of obtain
>owner gone
>
>The rule that we intended, and told everyone about, and tried
>(unsuccessfully in some cases) to get people to implement was:
>There should be no owner-gone storage.
>
>That meant that if you obtained common storage that needed to persist
>beyond the life of the obtainer, then it should not be owned by that space,
>but should be owner=system. Otherwise, you are wasting the space that the
>system must maintain in order to keep track of the fact that this now-gone
>space still owns storage.
>
>I personally would complain to a product owner who ended up with owner gone
>storage. They might blow you off, but perhaps they would (in my mind) fix
>("improve") their product. TSO/E was mentioned as one that obtains, and
>leaves stuff. Whether they do this or not, and whether they use
>OWNER=SYSTEM or not, I have no idea. But if they do that obtain, and do not
>specify OWNER=SYSTEM, then they could be prodded to update their code
If TSO/E or any other IBM component obtains storage and intentionally
leaves that storage after normal termination without specifying
OWNER=SYSTEM, is it APARable?
--
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
(fwd) Creating a full file test environment
On Wed, 12 Sep 2007 14:10:33 -0700, in bit.listserv.ibm-main bwstorts <[EMAIL PROTECTED]> wrote: >We are planning a full file test environment to better test our >applications. Currently, our testing happens on our production lpar >with very small vsam and DB2 files. We plan on mirroring our >application data to a test lpar and doing our development and testing >there. We expect to refresh the data from production once a month. > >I'm asking for some input on how others handle the need to fully test >their applications. some example questions: >1) do you use full files, and if so, how do you populate them? >2) how do you protect production from test work (people logging into >the wrong lpar, sending test print to production printers, etc.)? >3) any advice? Consider security. Depending on the country your organization is affected by various acts such as HIPPA in the United States (Health information privacy) and PIPEDA in Canada (privacy act). There is sensitive data in those files. Will it be masked? Will the test system be accessible from the Internet? What can people download to their PC's? How strictly controlled will the access be? Will this test LPAR also be used to allow the using departments to test their data changes? Should there be a separate LPAR with its set of files/tables for this purpose and how will access be controlled? Clark Morris semi-retired systems programmer and applications consultant. > >Thanks in advance. -- 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: z/OS 1.9 Features summary
On 31 Oct 2007 17:58:09 -0700, in bit.listserv.ibm-main you wrote: >> Sure they are trivial - until we move into an environment where there >> are multiple DASD sizes with different optimal BLKSIZE needs.The >> programmer shouldn't care what disk his files are in - the systems >> people should have the ability to quickly and easily move the files >> depending on current needs. When they move them, they should be able >> to adjust the buffering without recompiling and changing JCL. >> > >I don't understand what you're talking about. In today's world there is no >need for an application's programmer to know anything about BLKSIZE beyond >what the installation demands. Utilities can certainly move data between >different geometries and handle the reblocking without intervention. The >JCL and program don't need to specify a blocksize since the DSCB provides >such information. Where exactly is all the effort? > >Whether the programmer should care or not is irrelevant. In most cases, >they actually don't know which means that your point has already been made. >The programmer DOESN'T need to know. > >Just a question though.. How many different DASD geometries are being >encountered today under z/OS? I am curious about the environment you're >suggesting. 3380 and 3390 are still valid for disk. Tape blocksizes can be larger. I still believe that IBM needs to move to FBA. It will take 5 - 10 years but it is ridiculous that the optimal blocksizes for both 3380 and 3390 VSAM make inefficient use of the track if you want the CI to be in page multiples. It is even dumber since the actual spinning DASD is FBA. > >Adam > Clark Morris -- 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: z/OS 1.9 Features summary
On 30 Oct 2007 13:46:07 -0700, in bit.listserv.ibm-main you wrote: >On Tue, 30 Oct 2007 13:29:54 -0500, Dave Kopischke wrote: > >>On Tue, 30 Oct 2007 09:46:36 -0600, Howard Brazee wrote: >> >>>But why should a program care about block size? >> >>Funny you should ask this; We had a major project implement a couple weeks >>ago. To deal with the number of object moves, many of the libraries were just >>cloned and renamed at implementation time. During this, a couple pretty >>important PDS's were reblocked. A pretty benign change from my point of view. >> >>It turns out a program update process allocates one of these PDS's >>SHR,BLKSIZE=3200. This effectively reblocked the PDS. Every member in this >>PDS that was longer than about 40 lines was corrupted and innaccessible. >> >>That's a reason to care, but probably not the point trying to be made. There >>are code bombs waiting to explode. Even a seemingly benign change can >>trigger one. >> >Ah, but if the programmer hadn't coded BLKSIZE in the DCB but >left it zero and accepted whatever value was in the data set >label, the problem would never have occurred. The problem was >caused by the programmer's delusion that he needed to override >BLKSIZE. And if the OS, according to my idea, had not updated >the BLKSIZE, the data set would not have been corrupted. All you have to do to foul the works is forget to code BLOCK 0 or use SYNCSORT with certain input VSAM data sets which it assumes are RECFM = F or V depending and things go downhill from there. > >-- gil > Clark Morris -- 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: JES2 / JES3 in same plex
On 24 Oct 2007 05:34:12 -0700, in bit.listserv.ibm-main you wrote: >Thanks to all who have responded. per request from others, please respond to >the list so all can see, I didn't think many folks would be interested in this >topic. >the JES3 side is currently using a product called OMC-Flash for the jes3/sdsf >type of things. OMC-Flash will work quite well with JES2 unless they fouled up after 1991. I was responsible for the conversion of the data center I was at from JES3 to JES2. > >for those that have done this, any GRS,WLM,XCF issues that you ran across ? > >Thanks Again > -- 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: IBM preannounces next IBMLink failure
On 30 Nov 2007 06:46:35 -0800, in bit.listserv.ibm-main you wrote: >I can only dimly remember planned outages. > >In my capacity as Customer Services Marketing Manager in Amdahl UK, one of the >metrics I had >to deal with was MTBUI - Mean Time Between Unscheduled Interruptions. It was >essentially >downtime with scheduled maintenance factored out - a planned two-hour slot >didn't count as >downtime unless it overran, and then an MTBUI incident was recognized and the >clock started >ticking. > >But as long ago as 1990 - some might say before - it became quite evident that >customers were >simply not able to take systems down for scheduled maintenance. A processor, >a storage bank, >a channel group - maybe. And it wasn't just Amdahl customers - we shared most >installations >with at least one other supplier and it was the same for them. > >Indeed, as long ago as 1979, I remember Eternit swapping MVS releases and >providing continuous >RJE service (and pretty continuous TSO) using shared spool. That's nearly >three decades. > >I can't think of another supplier who has outages like this. My personal >systems are set up >for automatic virus definition updates, automatic Microsoft patches, etc., and >they never >fail. > >I'd love to see someone try to sell a mobile phone with the caveat that it >can't be used >between 03:00 and 04:00 on Sundays because the network goes down for >maintenance. This seems like a great requirement coming from active and large customers like banks that IBMLINK must be 24/7/365.24. Always available since you never know when an outage can occur. I am certain the financial justifications can be written. The requirement could be submitted and also concurring PASRs. If I were still employed and could get management permission, I would be glad to participate. You might also threaten to embarrass them at the annual meeting if you are a shareholder. Also ask on what platform IBMLINK runs and if not z, why not. I'm a shareholder but not big enough to afford to go based on my dividends. -- 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: Fw: Copy replacing without pseudo code
On 3 Dec 2007 05:54:20 -0800, in bit.listserv.ibm-main you wrote: >You are absolutely right, but this issue keeps coming up because the >behaviour of the compiler in this instance isn't exactly 'intuitive'. I'll >bet that 9 out of 10 programmers who read the manual come away with the >impression that COPY REPLACING is a string replacement function and are very >disappointed when that turns out not to be the case. If you would like COPY xxx REPLACING LEADING/TRAILING yyy BY zzz then check out whether there is an existing SHARE requirement for it in addition to the general requirement to support the 2002 COBOL standard. If there is (and I think I submitted it), then have your organization (company, university, etc.) file the appropriate concurrence with IBM. You might even make a stink about the lack of improvements in the language that is supposedly the one of the future. Personally, given IBM and other vendor actions, I believe it is a cash cow on a long term death bed. Clark Morris > >On Dec 3, 2007 8:37 AM, Bill Klein <[EMAIL PROTECTED]> wrote: > >> >> (text words are not QUITE the same as COBOL words). That is ALL the >> feature >> was designed to do and that is all that it does with current IBM >> Enterprise >> COBOL. >> >> There are "ways around" this restriction (discussed in this group) but the >> COBOL compiler simply will not (and should not) do what it isn't supposed >> to >> do. The '02 Standard did enhance the design of COPY/REPLACING and >> REPLACE. >> If this is really important to you, then you should communicate this to >> IBM >> via an IBM marketing REQUEST. Don't use this forum to "complain" about >> the >> compiler doing what it is designed and documented as doing. >> >> > >-- >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
COBOL gets no respect from IBM was Re: Where did the term "clip" come from?
On 10 May 2007 08:54:33 -0700, in bit.listserv.ibm-main you wrote: >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of John Eells >> >> The IBM Jargon Dictionary confirms my recollection that it >> came from "Change Label Information Program." >> >> http://www.comlay.net/ibmjarg.pdf > >Neat book! > >Here's one from there of possible interest to Bill Klein and "COBOLers": > >COBOL programmer n. A person whose experience >is limited to commercial applications programming. >This term, now rare, had negative connotations. >COBOL is not highly regarded in IBM; few people >in IBM choose to program in the language. > That explains why they are so brain dead as to not understand the need for native IEEE floating point, the other data types that became standard for COBOL with the 2002 standard such as USAGE BIT, and the need for a 64 bit mode to interoperate with the other 64 bit modules. Of course if they supported all of the data types in the new standard, they would have no excuse for lacking a mechanism to produce SMF record descriptions from Assembler or PL/X descriptions. >-jc- > -- 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: PSI MIPS (was: Links to decent 'why the mainframe thrives' article)
On 20 Jul 2007 23:35:18 -0700, in bit.listserv.ibm-main you wrote: >- Original Message - >From: "Timothy Sipples" <[EMAIL PROTECTED]> >Newsgroups: bit.listserv.ibm-main >To: >Sent: Friday, July 20, 2007 10:43 PM >Subject: Re: PSI MIPS (was: Links to decent 'why the mainframe thrives' >article) > > >>Re: Supposed factor improvements over time in the integer performance of >>processors, there are some faulty numbers in this discussion, or at least >>misleading. It has to do with cores versus chips. > >>Dean, with all due respect, no matter how much you try to fuzz it, they're >>not directly comparable. The X86 architecture going to two cores and now >>quad cores was the only way X86 engineers could simulate a Moore's Law >>improvement. But the dirty little secret is that two cores most definitely >>does not equal doubling the clock speed of a single core. I think your >>math is pretending otherwise, but that's not the real world of business >>computing. > >I didn't do any math. I reported SPECint numbers - for both single core and >dual core. The numbers I provided were single processor, single core >results up to June 2006. > >> Another dirty little secret is that today's typical X86 >>software is lousy at taking advantage of multi-cores. And yet another >>dirty little secret is that almost all software vendors charge more for >>multi-core, so moving to the supposedly higher performance multi-core >>design might actually raise your cost of computing. (This is a very real >>problem now. Single core processors are still in demand, especially for >>light duty test servers, development servers, branch servers, and >>education/training servers, in order to minimize the cost of the software.) > >Why is this relevant to the discussion, except as a way to again move it >away from the question of processor performance. I understand the desire to >defend the faith at all costs - but this is just a simple little issue. If >processor performance doesn't matter, then why is the fight to defend it so >fierce? Either mainframe CPUs are slower, or they are not. Instead of >all these 'dirty little secrets', and 'leading technology' arguments that >have nothing at all to do with the issue, except to widen the discussion so >it can be 'won', we either present the figures and deal with them, or just >agree to disagree. I suspect that slower or faster may depend on workload. If there is a lot of decimal arithmetic (native on z, simulated in part or all on Intel, Power and RISC), the mainframe will be a lot faster for the arithmetic part. On the other hand, IBM came out with XPLINK and other tweaks because C/C++ performance was so bad on z series. I would like to see a test with optimized COBOL and web server on the various platforms. Also a COBOL and DB2 benchmark across platforms would be useful. As someone who likes COBOL and z, I am dismayed by the probable demise of both in part because of what I believe to be bad management of both products. > >>Oh, there's another dirty little secret. Execution errors are becoming >>more frequent as clock speeds increase, temperatures rise, and densities >>shrink. Keeping those electronics flowing in the right places is getting >>tougher, and more often they're leaping out of their little cages resulting >>in two plus two not equalling four. This is most unacceptable in the >>financial transaction processing world, for example, which is why IBM >>mainframes protect against execution errors. It's yet another metric >>SPECint doesn't seem to report, the long-term processor error rate. > >This, of course, is a red herring. We've already had Tom Marchant claim >that IBM is leading in process technology, and now we are hearing that these >improvements are causing increased errors that are unacceptable for >mainframes. This is typically called FUD. > Since a large percentage of PCs are sold with non-parity, non-ECC memory, I doubt that anyone knows the true error rate of Intel processors. I wonder how many glitches attributed to Windows are actually hardware problems. It would be instructive to know how many times a processing error is actually detected by the z hardware. > >>If you want to look at integer performance on a benchmark, stick to per >>core numbers if you're comparing cores. And you'll discover that processor >>engineers are struggling to increase core speeds, and Moore's Law has >>probably stalled already. Maybe that's why Intel is cutting back on R&D? >>:-) > >More FUD. As I said - I compared single chip, single core performance. > >>This multi-core problem is not new to IBM. The solutions (plural) require >>a total system design perspective, including software. > >Such as Linux and open source. Yep, only IBM has the answer. The FUD gets >more intense. > >I think John Gilmore is right - this thread has probably run its course. >I'm a staunch mainframe advocate, but I think it's OK to give credit where >it is due. I haven't seen
Re: web IBMLINK down again -SEV1 32656350
On 31 Jul 2007 09:39:32 -0700, in bit.listserv.ibm-main you wrote: >Steve > >How about if someone on the list who has a web site set up a standard e-mail >to send to the illustrious Mr. Palmisano. The e-mail could consist of the >eloquence we so often find in these posts regarding how vital a tool this is >and how it was trumpeted by IBM as being so 21st century etc. etc. > >Then we just need everyone on the list who feels aggrieved - probably many >more than fruitlessly vent their bile in posts to us all - to click on the >link and - just maybe - something good will come from it. > >If someone in IBM needs to spend time analysing these e-mails in order to >block them perhaps some ingenuity can be applied - and there's so much of >that available here - to defeat him/her. The effort to block the e-mails >would require some management focus and it just might occur to the besuited >ones that solving the problem at source would be a better use of resources >than fending off the brickbats. > >Incidentally I guess mentioning the money angle is also important in getting >the besuited ones attention even if actually getting the unmentionables >involved would be most improbable. If the web access is not on a z system, should it be a candidate for a Reboot Hill story. > >Chris Mason > >> rest snipped -- 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: Theft of spindles was Re: PCI Compliance - Encryption of all non-console administrative access.
On 2 Aug 2007 02:24:21 -0700, in bit.listserv.ibm-main you wrote: >Ron Hawkins wrote: >> Clark, >> >> Could this really be a true story? The few boxes that attach to mainframes >> would have triggered a SIM the moment someone unlatched and pulled the drive >> - a highlighted, non-scrolling error message on the console. >> >> And of course the box would have called home to report the failed drive, and >> within an hour or two the CE/FE would have been asking where the missing >> drive canister had gone. >> >> Any computer room worth it's salt would have a log of who had gone in and >> out and the culprit would have been nabbed before you could say >> rumplestiltskin. >> >> A box of spares next to a MF perhaps... Sounds like an urban myth to me. >> >> Ron >> >> PS That would be a hell of a PC running SSA or FCP HBAs. > >No, we use to run HDS dual-SCSI-port drives, as the interface so common >in PCs. > >But seriously: I think it is *much easier* to copy the information than >to steal physical drive modules. If one's datacenter is well protected, >strict RACF and other security rules are enforced, then usually server >room is also well protected. > >Regarding to Timothy's message about encryption - now I understand your >point. "Encryption everything" doesn't mean i.e. SYSRES and SPOOL. >Timothy , you mean all sensitive data, don't you ? SPOOL can have a lot of sensitive information in readable format. Reading it is not for the technically ignorant. > >Regards >-- >Radoslaw Skorupka >Lodz, Poland -- 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: How-TO: Non-production CA-7 usage
On 20 Aug 2007 05:38:39 -0700, in bit.listserv.ibm-main you wrote: >I'd like to use CA-7 to automate jobs, but in our shop it takes literally >2+ months of 1970's paperwork to get a job start approved, and there are no >guarantees that it will be accepted. One only has to attempt this once to >never try it again. So our current solution to this obtuse behavior is >using Windows Scheduler. Can you have production and test instances of CA-7 or any other job scheduler? I always have believed that not being able do a scheduled batch testing with the special control records used by the schedulers was a problem. > >I'd like to know how different shops handle the scheduling of jobs, that >aren't "PRODUCTION", for the benefit of testing, paralleling, and other >non-production types of work. Does anyone have an alternate access for >this kind of work - a way around production schedulers who have a >monopoly on exploiting CA-7? > >Thanks > >Michael > >> rest snipped -- 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
(Mainframe has competition was fwd) Re: COBOL Compiler for Windows
The following discussion on comp.lang.cobol may prove interesting. I would be curious to read if any of the major claims such as American Airlines Sabre moving totally to Unix are wrong. Clark Morris On Wed, 30 Apr 2008 22:38:36 -0500, in comp.lang.cobol Robert <[EMAIL PROTECTED]> wrote: On Wed, 30 Apr 2008 10:58:52 -0600, Howard Brazee <[EMAIL PROTECTED]> wrote: >On Thu, 1 May 2008 02:56:51 +1200, "Pete Dashwood" ><[EMAIL PROTECTED]> wrote: > >>> It's not free, though. It's not even cheap. Emulating the mainframe >>> operating environment is not trivial. >> >>Sure it is. >> >>But the people who want it are used to paying through the nose so why >>disappoint them? >> >>One day the mainframe world will wake up to the fact that they have a >>choice. There WAS a time when mainframe hardware was the only game in town >>and vendors (both hardware and software) could charge anything they liked. > >Why should they worry about emulating the mainframe environment on a >PC? > >The future of mainframes is as a component in the system. It will be >the database full of security rules and powerful behind-the-scenes >action.There is no reason to duplicate real data on PCs (security >audits will make sure we don't), nor to create allowable test data. >The DBAs and systems people will handle that component, just as the >network people handle the routers and ports. Unix database servers are already doing the same, cheaper. For example, Sabre (airline reservations, Travelocity) cut its total expenses 50% when it switched from mainframe to Unix. It handles 15,000 transactions per second. The database resides on 17 HP S86000 boxes (now obsolete). For example, US telephone networks run entirely on Unix machines. About 10 servers handle 200,000 transactions (calls) per second. Each transaction creates at least one database row. For example, PULSE, the largest ATM/EFT clearing system in the US, runs entirely on Unix servers. "The base zSeries 990-332 machine, without disk and memory, costs around $15 million. If you had to beef it up with an appropriate amount of memory and disk, the mainframe hardware might cost $30 million. If you have to add monthly software fees for three years to this machine, it is probably on the order of $50 million for this machine over three years, including maintenance. Mainframes don't have list prices--which used to be against the law for IBM--so it is hard to say for sure. Even if you assume a 50 percent discount, after adding in the software costs, you are talking about $55 per TPM. That's a 10 to 1 price premium. And it will get worse as the Power6 and Power7 generations roll out, unless IBM consolidates the zSeries into one of these future Power-based servers. And that is why many people believe IBM will do just that, as it has already done with its proprietary OS/400-based servers." http://www.itjungle.com/tug/tug120204-story02.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: Java Batch
On Fri, 02 May 2008 22:01:10 +0200, Thomas Zierer <[EMAIL PROTECTED]> wrote: >JZOS has become part of Unix System Services in z/OS. Handling is very >easy, especially if combined with other Java tools like ANT. There is an >interesting sample shiped with JZOS: Installing an running a Apache >Tomcat server as a batch job or started task. It really takes only a few >minutes to get the server up and running. > >I havn't made any research on performance, but the last I've heard is >that Java is about 30% slower as COBOL, which is reduced, if your S/390 >uses special chips. Also IMS uses now special regions, JMPP and JBMP for >Java apps but I'be have no experience with this. This gets complicated and speaks as much to IBM marketing as anything else. Java batch may well take 30 to 50 percent more CPU yet cost less because the Java is run on a zAAP which doesn't count toward capacity when calculating software pricing. If someone got bright on some of the Java functions, this may be even less. IBM pricing can be a driving factor to moving to another language. What the marketing droids fail to realize is that once all of an installations work load is moved to C/C++, Java and the web, it becomes easy to move to another platform. Of course it is harder to move to another language than the enthusiasts of X claim. This is especially true if people don't really know how the current system operates, down to the various subtleties. I wonder if any organization knows even a good percentage of their components and the implications of interaction. The number of fixes needed for any of the operating systems of affliction or choice from the various vendors leaves me skeptical. > >Regards > >Thomas > > >Pakku schrieb: >> I've spent much of this morning looking for some comparison between >> the performance of Java and COBOL for batch programming on z/OS. I >> haven't found any useful information and am hoping I might find some >> here. >> >> I know that IBM bought the JZOS product a couple years back with the >> intent of enabling Java in the batch world. >> Has this taken off? >> >> Also read somewhere that given that Java has to be reinterpreted (from >> the bytecode produced by compilation) by the JVM at runtime, there is >> no way it could outperform COBOL in classical batch processes like >> payroll or month-end credit card statement processing. >> >> Is this so? >> >> Would really appreciate hearing from anyone who has experience with >> JZOS or other forms of running batch Java on MVS. >> >> Thanks! -- 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
Posting on timetable software running z was (fwd) Re: After Yesterday, No One Will Ever Again Wait For SEPTA ( Phila PA )
Note the application and the fact it is running on z series assuming Hans (who normally has a good track record) is correct. I kept the whole posting so that you get a flavor of the type of application and the cpu requirements. Clark Morris On Mon, 2 Jun 2008 02:32:56 + (UTC), in misc.transport.rail.americas Hans-Joachim Zierke <[EMAIL PROTECTED]> wrote: > >Merritt Mullen schrieb: > > > Unfortunate name. Probably "HaCon Fahrplan System" or somesuch. The big companies will run checks for new products, to avoid any kind of unfortunate connotation in any major language, but when Hacon developed the software in the 1980s, it was a company with less than 10 employees. The first timetable CDs were sold for hundreds of DM a piece, to major travel bureaus etc. Then there was a "BTX" online system in the early 1990s, where you could use it for a fee. Change came, when a student wrote a script, which generated a mail-to-server service on a university host. I think this was at a time, when the www didn't exist yet, or at least Mosaic didn't, and Internet access was available for 5 digits per year. When Internet access became more common, the figures on the university computer went up, which convinced DB to set up a public server, in 1995 or so. > You would want to buy a "hafas" software application? > In fact, yes. If they can handle 1.6 million connections in one hour, out of 40 stations and bus stops plus 40 million adresses, with response times of very few seconds, then it might be good enough for me as well.;-) But the absurd part is: While the DB server runs on Linux (and an IBM mainframe cluster), the consumer offline PC version is only available for Windows. >Hans-Joachim > > >-- > Busy in a narrow valley: > > http://www.railpictures.net/images/d1/6/3/1/8631.1188306000.jpg -- 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
Comments on Re: Is there a mainframe skills shortage?
The following posting is a comment on an article about mainframe skills shortage with the article and comments by Pete Dashwood who believes both COBOL and mainframes are on life support and that there are far more cost effective platforms than the mainframe. On Thu, 29 Mar 2007 17:28:57 +1200, in comp.lang.cobol "Pete Dashwood" <[EMAIL PROTECTED]> wrote: > >"Frank Swarbrick" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> http://searchdatacenter.techtarget.com/tip/0,289483,sid80_gci1249301,00.html >> ?track=NL-576&ad=583919&asrc=EM_NLT_1201842&uid=1303979 >> >> Frank >> > >This article really lightened my day... It is raining here (bloody >Autumn...Grrr...) and I finally managed to get a COBOL component working as >a Web Service (after days of frustration), so I decided to take a break from >serious work and respond to the article. Since some of you can't see it, >I've reproduced it here and interspersed my comments... Everything in quotes >is from the article and I've used a few dashes to separate out the article >and the responses. A group of equals signs represents the beginining of a >response...If you want to remove my insightful witty observations and simply >reconstruct the article, just delete everything between a row of equals and >a row of dashes ;-)... > > >"I've got a lot of respect for much of the market research that Gartner >produces -- but in this case I believe that Gartner is just plain wrong. " > >Immediately, we realise this is going to be insightful...:-) > >As far as I'm concerned, I've NEVER seen anything from Gartner that looked >even remotely probable, never mind likely...Still, it's nice to see that at >least one of the Faithful is backsliding...:-) > >- >"In a recent research note, "Impact of Generational IT Skill Shift on Legacy >Applications", Gartner suggests that a pending, projected decrease in >mainframe-skilled individuals may be a reason to migrate to other, >"more-modern application platforms". >The logic is that as baby-boomer mainframe coders and administrators leave >the workforce over the next five to seven years, mainframe shops >(particularly the smaller ones) are going to have great difficulty managing >their mainframe environments or maintaining legacy COBOL code. Thus, IT >executives should start planning to go to other platforms. " > >== > >While this is certainly a consideration, there are many much better reasons >to migrate away from COBOL... (Interoperability would be a major one in my >book...COBOL does NOT play nicely or easily with other languages. Some >others: COBOL does not sit well on the Network (unless the "network" is >being run from a centralized mainframe), COBOL objects are difficult to >share (unless you wrap them as something else, and always assuming you even >took the trouble to learn OOP in the first place...), COBOL has a major >emphasis on maintaining Source Code and this is error prone and >outdated...etc.) > >- > >"However, this Gartner report failed to identify which specific skills were >"at risk." Additionally, it failed to identify that there is a skills >shortage across the entire IT industry and not just in the mainframe market. >Furthermore, this mainframe skills shortage problem is geographical; and all >of the new improvements that IBM is making in mainframe management may >actually reduce the number of people needed to manage mainframes in the >future, as well as reduce the skills needed to manage mainframe >environments. " > >= > >That seems pretty fair comment. Looks like its "System Programmers" who are >at risk :-) > >- > >Based on interviews with IT executives, university professors, IT >recruiters, and IBM: > >= > >I had coffe with my Boss, my tutor, my pimp, and our IBM rep :-) > >-- > > a.. Some mainframe skills are indeed in short supply; > b.. Other skills are readily available (especially Java/Linux skills); >and, > c.. The projected need for an army of mainframe-skilled IT professionals >to replace the existing generation of soon-to-retire mainframers may never >materialize. >COBOL programming > >The term "mainframe skills" needs to be better defined. In my research, I >found that IT managers, recruiters, and university professors have generally >separated "mainframe skills" into four groups: > > 1.. COBOL programmers (applications developers and code maintainers); > 2.. Administrators and managers (with CICS, zOS, and systems management >skills); > 3.. Operations/planning staffs (business/design consultants, DBAs, and the >like); and, > 4.. New applications designers (Java/Linux
(fwd) Re: Lnnnnn tapes mystery
On Tue, 24 Apr 2007 22:44:20 -0300, in bit.listserv.ibm-main_dummy Clark Morris <[EMAIL PROTECTED]> wrote: On 24 Apr 2007 04:42:48 -0700, [EMAIL PROTECTED] (Knutson, Sam) wrote: >I have never IPLed SAD off anything but disk. For the other things you >can IPL from a tape unit like FDR, DFDSS, ZZSA you can just repeat the >IPL function till you get past the labels to the program. I always kept >the FDR install tape in the computer room for just that reason as it was >a ready made Stand Alone tape. > >From the FDR doc > >"SAR SAR (Stand-Alone Restore) is an IPLable program which runs >without an operating system, whose main function is to restore FDR >full-volume backup tapes at a time when you cannot execute normal FDR >because your MVS system cannot be IPLed. This could occur if disk >volumes required for MVS IPL (such as residence volumes, paging volumes, >spooling volumes or library volumes) are unavailable due to hardware or >software problems. SAR can also be used to setup new data centers by >restoring backups of volumes prepared at another site. SAR is described >in detail in Section 15. > >There is an IPLable copy of SAR in the first file on every FDR >distribution tape, but since that is a labeled tape, five hardware IPL >functions are required to bypass the labels and load the program. >Innovation recommends that you copy the SAR IPL text to an unlabeled >tape or to one or more disk >volumes for quick IPL when required. Once loaded, SAR can restore >multiple FDR backup tapes without an additional IPL." > >Also of interest > >"SAR IPL OPTIONS >An IPLable copy of SAR (Stand Alone Restore and backup) is on every >Innovation documentation CD produced since September 2005. Section 15 >contains directions for IPLing SAR directly from the CD on your HMC >(Hardware Management Console). SAR is also available on the Innovation >FTP site. If your HMC has Internet access, you can IPL directly from >FTP, or you can copy the files to a CD and IPL from it." > My boss at a former installation had me put FDRSAR as the first file of every dump tape. That way we knew where the standalone restore was and also it was easy to make sure that the standalone restore matched the version of FDR we dumped the file with. If you had a dump and the tape was good (with 3420's that was a definite if), you definitely could restore it. > >Being prepared by having current and tested versions of the standalone >tools on CD, disk, or tape is a really good idea. > > >Best Regards, > >Sam Knutson, GEICO >Performance and Availability Management >mailto:[EMAIL PROTECTED] >(office) 301.986.3574 > >"Think big, act bold, start simple, grow fast..." > >> rest snipped. -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On 8 Aug 2006 15:41:36 -0700, in bit.listserv.ibm-main you wrote: >> >To be honest, I dislike all those "autocust" things. <<>> >> I never found that it made the install any easier. Same >> with the rest of them. Mostly front ends to SMP/E, to cover up for >the >> fact that the vendor doesn't have a clue how to create proper SYSMODs. >> Let alone HOLDDATA. > >I can't speak for all vendors, but trust me the reason is NOT because >the vendors don't know how to package SMP/E deliverables. There is (at >least in the ones I have dealt with) a full SMP/E install under those >covers. The autocurse installers exist because a significant number of >customers ask (demand!) them. The ibm-main audience is not necessarily >typical because there are a lot of customers who can't spell SMP/E let >alone configure high end software products. Could people comment on the other IBM maintenance methodologies, the ones for VM, VSE, AIX and OS400 and how they compare to SMP/E? If anyone has relatively current knowledge of the Unisys A series or 2200 series methodologies those would be of interest. I have often felt that SMP/E got the job done but required a lot of manual effort on the part of the developers, left holes for the installers such as no good way to hand panel prepping or compilation in ISPF, and was generally arcane. While I like the ease of applying Windows fixes when they work, I am in a position of trusting the vendor more than I would like. > >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: z9 & SoftwareAG
On 9 Aug 2006 04:49:34 -0700, in bit.listserv.ibm-main you wrote: >SNIP > > Yep yep yep. We're looking to move from z900s to z9s, with a small MSU >increase, big increase in real, and, IBM-wise, we'll save $600k. Bloody >brilliant. I'm in love. Add in SoftwareAG, and the savings is gone, and >then some. It is extremely discouraging. We've had several people >volunteer their time to rid ourselves of this albatross. > >End_of_SNIP > > Yep, the constant barrage of increases every time we bump up our >processors to keep up with demand is hurting the ISVs, as well as us. >Funny thing about it, though, are the costs that are associated with other >platforms. Last week 11 PALLETS of old PCs and servers and such went to >salvage, and that wasn't even all of it! > >Vendors: heed the call; help us contain costs so we have something to run >your software on! > Spec out a serious migration plan that also addresses other business needs as ammunition for telling whatever vendor does this sort of thing that they can be on the way out the door with no chance of return. Also find the pit bull negotiators in your organization and see if they are willing to go after these vendors. > > > >Daniel McLaughlin >ZOS Systems Programmer >Crawford & Company >PH: 770 621 3256 >* >Victory is won not in miles but in inches. Win a little now, hold your >ground, and later, win a little more." >? Louis L'Amour > > > > > > > > >-- >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
SMPE packaging was Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On 9 Aug 2006 20:49:25 -0700, in bit.listserv.ibm-main you wrote: >> I guess that means that you think they can't install MVS. In all the >> years >> I've been in this business, people have been telling me that this >group or >> that is full if idiots. People who were incapable of learning, or >worse, >> that anything that they might learn will only make them screw things >up >> worse. "A little knowledge is a dangerous thing." I call it the >user- >> dummy syndrome. I have variously been told that users, programmers, >> operators, analysts, vendors, managers and customers are dummys. > >-I- am not telling you anything of the sort. I am telling you that >customers who write big checks for enterprise software products have >made enough fuss about this issue that pretty much all of the vendors >provide gooberware to assist with installation and configuration of >their software. You can choose to believe me or not, I won't lose any >sleep either way. Here I agree with the management that wants something simpler than SMP/E for installation. I also believe that the overall design needs a revisit given the following: 1. A RESTORE can be painful if it involves more than one SYSMOD or a chain. I don't know if I ever did a restore, finding it simpler to go back to a previous system or to move forward. 2. SMP may still not cover all of the entities (I'm not certain if the printer FCBs were covered for example) and still may not support such things as panel compilation or prepping. 3. The reporting, while probably improved still may need further work for things such as system HOLDS, where grouping like reasons would reduce the amount of review. 4. The dependency maintenance must be difficult to keep straight and any aids for this would be of use for all vendors. 5. We may also need to react faster to security fixes as the platform is used more and more for Internet business. 6. Having a common install process for all system related software that both allows each vendor's code to be kept separate but also checks for interdependencies would be extremely useful. Note this is also needed for DB2, IMS and CICS. 7. If the philosophy in Websphere Developer could be adapted this might allow applications people to be moved into systems easier. Not knowing enough about the product, I can't judge whether this would be disastrous. 8. SMP should be able to control and run source modifications for any language supported by the z series. This includes COBOL. After all JARS (SMF reporting) was written in COBOL. If IBM would implement the requirement to implement the bit and native binary data type in the 2000 standard COBOL could work with any IBM defined data area. Reference modification already makes it simple to rearrange the SMF type 30 record. It will be fun getting to a new or even noticeably improved system and the definition of what new and improved should look like and do will not be easy. However if it makes it easier to package code, install same, update it and modify it with greater safety it will be well worth the aggravation. > >> I can assure you that many vendors produce inferior SMP/E. SMP/E is a >> powerful tool, and when the SYSMODs are coded correctly, it makes >> installing and maintaining a system easy. When PTFs are sent without >the >> REQs coded properly and the vendor tells me to BYPASS ID, I have to >wonder >> why they bother with SMP at all. > >So you say. On the other hand, you could apply the same reasoning to >vendor employees that you did to your own peers. They are just trying to >do the best job they can for their customers. That's not all good or all >bad. It just is the way it is. > >Installation aids may NOT be to your taste perhaps, but the vendors >aren't providing them to p*ss you off and they're not all incompetent. >Ask yourself why the vendors would bother doing all that "extra junk" if >their customers weren't asking for it? > >It is all very well to say you don't like assistance from the autocurse >software. Fine. I could care less. What I am really annoyed about is >this constant blather that (all) vendors don't have a clue what they're >doing. Perhaps you could do better, but I wouldn't bet a paycheck on it. Given the cost and complexity of producing this sort of thing, I believe the idea is good, the customer need is there but that it should be a multi-vendor effort (possibly an open source style operation like Linux or CVS). > >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: SHARE bound air traveler's TSA change liquids prohibited in carry on and new security nationwide
On 10 Aug 2006 09:18:20 -0700, in bit.listserv.ibm-main you wrote: >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of Knutson, Sam >> >> Hi, >> >> We had one associate today that took 2.5 hours to get through >> security in Atlanta today. > >Oh, joy. "I just can't wait" to see the effect at ORD. :-( > >One of the reasons I quit the USMC way back when was because I got tired >of "hurry up and wait" > Those close enough might want to consider driving, taking Amtrak or taking the bus. Anywhere from Raliegh to Boston or Albany and west to around Pittsburgh might be tolerable by train as might the overnight train from Birmingham and Atlanta. If the ban is still in effect when my wife and I are traveling in November, it will be a problem. >-jc- > -- 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: Java Packed Decimal
On 10 Aug 2006 17:30:49 -0700, in bit.listserv.ibm-main you wrote: >In <[EMAIL PROTECTED]>, on 08/09/2006 > at 04:24 PM, Clark Morris <[EMAIL PROTECTED]> said: > >>As I understood Chuck Stevens who was the Unisys COBOL representative >>to ANSI X3J4 and a member of the technical support team for their >>compilers, Burroughs large scale B7500 and beyond which I believe >>became the A series, > >The B6500 and B7500 were the original processors in the line that >succeeded the B5000[1] line. As I recall there were B6700, B7700, >B6800 and B7800 processors in the line prior to the merger with UNIVAC >and the renaming of the line. > >>stopped supporting full decimal arithmetic > >Do you mean that they stopped including the operators in the >processors or only that the compilers stopped generating code for >them? Given that Burroughs could require recompilation of programs for either hardware or software upgrades, I read Chuck's statement as meaning the processors no longer had decimal arithmetic instructions. This agrees with what Mike Cowlishaw has on the IBM decimal arithmetic web site - www2.hursley.ibm.com/decimal (google on IBM decimal arithmetic if I got it wrong). > >[1] Despite what you may have read, the B5000, B5500, etc. had >radically different architecture for the B6500 and its friends. > -- 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
Will there be HOLDDATA for ACCEPTED sysmods was Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On 13 Aug 2006 15:51:35 -0700, in bit.listserv.ibm-main you wrote: >At 01:57 -0400 on 08/12/2006, Arthur T. wrote about Re: Vendor JCL >(was: WHY IS JCL ALLERGIC ... ): > >>On 11 Aug 2006 21:02:35 -0700, in bit.listserv.ibm-main >>(Message-ID:<[EMAIL PROTECTED]>) >>[EMAIL PROTECTED] (Robert A. Rosenberg) wrote: >> >>>If I do the RESTORE the current way and back off 10 SYSMODS only to >>>do the APPLY and apply 9 of them, why is this "safer"/"more >>>correct" than just doing a forward APPLY of those element(s) of the >>>backed-off SYSMOD that were taken from the other 9 SYSMODs during >>>the Apply step that was done after the Restore? >> >> I've cursed SMP for the same reasons. However, I can think of >>reasons that the current method is safer or more correct: >> >>1. If you've Received Holddata between the Apply and Restore, it >>may be that one of those other Sysmods is PEd, SUPed, or some such. > >See my reply to point 3 below. I do not think that it is hard to do a >scan to see if Holddata issued AFTER the date of the APPLY would have >blocked the APPLY (I think that the date of the APPLY is stored in >the element's entry as well as each HOLDDATA entry having a similar >"issued" date). > Will the HOLDDATA even be loaded for something which has been ACCEPTED? If so will the SYSMOD be shown in an error report. At one time, I was told that HOLDS for Accepted SYSMODS were effectively discarded. -- 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: Why is JCL allergic to lower case?
On 15 Aug 2006 06:44:58 -0700, in bit.listserv.ibm-main you wrote: >I'll second the motion to allow lower case in JCL. In fact, I'd like to >see an option to allow "user friendly" JCL: While I like the idea, plan on major effort to convert JES exits, IEFUJI and IEFUJV among other things. I would prefer we start looking a command language be it REXX, one of the Unix shells or something else that would allow longer data set names, mixed case, less convoluted syntax etc. Obviously JCL will have to be supported for the next decade but the limitations associated with it are probably so deep in the guts of z/OS that we would bleed if they were relaxed. > >1. For compatibility, there would need to be an installation >configuration option to permit or disallow "user friendly" JCL. > >2. It should allow mixed case JCL keywords and parameters. Of course, >quoted strings would not be folded to upper case. > >3. Positional "keyword" parameters (for example, RLSE) should become >simply "keyword" parameters. > >4. Continuations should be able to start anywhere after column 3. > >5. JCL should not be restricted to columns 1-72 of LRECL=80, but should >support RECFM=F or V and larger LRECL's. The last 8 columns of RECFM=F >and the first 8 columns of RECFM=V should have automatic sequence number >detection and would ignore sequence numbers as appropriate. > >I'm sure that there are many other features that would make JCL even >more user friendly. > >Don Williams >[EMAIL PROTECTED] >(919) 966-3968 >UNC Hospitals >Information Services Division >321 Meadowmont Village Circle, 2nd Floor >Chapel Hill, NC 27517 > >"The time is always right to do what is right" -- Martin Luther King, >Jr. > >-- >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
Secuirity when application on PC, database and files on mainframe was Re: The Fate of VM - was: Re: Baby MVS???
On Wed, 16 Aug 2006 09:55:02 -0600, in bit.listserv.ibm-main you wrote: >On 16 Aug 2006 08:28:34 -0700, "Mickey" <[EMAIL PROTECTED]> wrote: > >>Moving to a PC based platform is the best way I know of to engage in >>empire building. I oft times suspect that some managers do it for just >>that reason. Managing 5 people makes you a manager, managing 40 makes >>you a big muckity-muck. >> >>Mickey - PC stupid and staying that way > > >Sort of.The way to increase your empire is to increase your >responsibilities that require an empire. The way to fund this is >incrementally. > >The incremental cost of providing a single Web based service to your >customers is low. Get an intern and a PC and you have a demo >project. > >Slowly build on it until it until you have your empire. At that >time, it can be determined that the applications would be more >efficient on a mainframe - but conversion is expensive. > >The advantage of PCs isn't cost - it's agility. The manager who >wants to innovate picks the platform that allows him to be in control. > >For the most part, that's good (not for us, but for the company). But >recently we have discovered the costs of not having secure, reliable >data.Centralized databases and database security is the new >bailiwick for mainframes.Forget the applications - they will >continue to move towards the more agile platforms.But security and >reliability need to be rock solid. Which means centralized, where >the mainframe has a cost advantage. > Unfortunately, the application is the entity invoking the security so if it is compromised and can log on with the appropriate authority, the mainframe will spill all information associated with that application. Given that and the difficulty of building security into any application regardless of platform, I really wonder how secure mainframe applications are, especially when they have to be accessed via the Internet. -- 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: DAF & IEFUJI
On 16 Aug 2006 06:15:07 -0700, in bit.listserv.ibm-main you wrote: >Greetings, > >For those of you that are members of SHARE, I submitted a SHARE >requirement regarding this. One of the problems is that the user-id is still only 8 characters. This is more and more of a limitation since most other platforms support longer names (and passwords). We probably should be looking at what overall changes are needed. > >Cheers... > >Michael > >http://www.share.org/Reqs4Logon.cfm > >== > >Requirement#: SSMVSE064958 > >Status: Open for Discussion > >Title: Provide System Option to Populate Userid in SMF Records >Description: Currently the user identification field of the SMF Common >Exit Parameter Area is initialized to blanks by the system. This user >identification field is used to create nearly thirty unique SMF records >such as SMF Record Type 4, 5, 6, 10, 14, 15, 17, 18, 20, 25, 26, 30, 32, >34, 35, 36, 40, 42, 60, 61, 62, 63, 64, 65, 66, 67, 68, and 69. To >effectively use this field, every z/OS customer needs to develop, test, >install and maintain a system user exit to populate the user >identification field of the SMF Common Exit Parameter Area with the >current userid. An SMF system option should be added to govern if the >system should populate the user identification field of the SMF Common >Exit Parameter Area with the current userid instead of initializing it to >blanks. > >Benefit: SMF records are the heart of the integrity on the z/OS platform >and need to >be a complete historical audit trail. Legal initiatives such as California >SB 1386, GLBA, HIPAA and SOX as well as the general strengthening of >accountability, auditing, governance, security and transparency have all >put an increased focus on computer systems and their integrity and >auditability. Providing this function at the system level would reduce the >complexity of managing a z/OS system and also increase the amount of >useful information in the system audit trail. > >Time Limit: The sooner the solution is delivered, the sooner the benefits >would be realized. > -- 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: Why is JCL allergic to lower case?
On 18 Aug 2006 05:16:53 -0700, in bit.listserv.ibm-main you wrote: >In <[EMAIL PROTECTED]>, on 08/15/2006 > at 09:18 PM, Clark F Morris <[EMAIL PROTECTED]> said: > >>While I like the idea, plan on major effort to convert JES exits, >>IEFUJI and IEFUJV among other things. I would prefer we start >>looking a command language be it REXX, one of the Unix shells or >>something else that would allow longer data set names, mixed case, >>less convoluted syntax etc. Obviously JCL will have to be supported >>for the next decade but the limitations associated with it are >>probably so deep in the guts of z/OS that we would bleed if they were >>relaxed. > >The deeply buried limitations of JCL are not in things like case and >record length, they are in things like field sizes. Handling long >record, RECFM=VB and mixed case would be a piece pf cake; allowing, >e.g., DSN longer than 44 bytes would be a nightmare. > And these things are passed from JCL to all of the necessary components of z/OS. However, case folding or whatever solution is found for allowing entry of lower case has to be accepted and handled by all recipients of the data depending on the solution. If it is handled by the JCL interpreters, there are fewer places but still the number of places could be non-trivial. Record length also might impact in strange places. -- 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
Trunc(OPT) causing problems was Re: SLIP trap for "wild branch"?
On 30 Aug 2006 00:49:08 -0700, in bit.listserv.ibm-main you wrote: >Hello John, > >One "thing" which happened to our CICS transactions after we increased our >ECSA size were "random" wild branches. > >Not every instance of a transaction would break.but many did. > >Why? > >Increasing our ECSA size moved the EDSA up the region, so that many >transaction programs etc were being loaded higher up in memory. > >The transaction that broke were accessing storage above "1,000,000,000". > >The transactions, written in COBOL, were making use of the ADDRESSING (I >think I have that correct), but had been compiled with TRUNC(OPT). >The COBOL variable to hold the address was adequate for a hex number, but >were being truncated at the high order because the arithmetic was being >performed in decimal. Addresses greater than 9 digits were being used. > >We re-IPLd with smaller ECSA to allow more of the transactions to >completeuntil all affected programs had been recompiled with TRUNC(BIN). Was the code moving non-decimal numbers into the fields used for addresses. I did quite a bit of experimentation with TRUNC(OPT) versus TRUNC(BIN) and found the following: 1. If you display a field that is USAGE BINARY (or COMP) truncation is according to PICTURE. 2. If one of the fields involved is not USAGE BINARY, truncation is according to picture even if the move is from S9(11) USAGE PACKED-DECIMAL to S9(9) USAGE BINARY. 3. If all fields involved are USAGE BINARY and literals are assumed USAGE BINARY, truncation is at the word boundary rather than by picture. A move from S9(8) BINARY to S9(11) BINARY followed by a DISPLAY of the S9(11) BINARY field showed that. 4. With the release of COBOL for MVS and VM that I was using, USAGE BINARY caused all arithmetic to be done in PACKED-DECIMAL thus involving CVD, do the arithmetic, CVB. This is supposed to have gotten better with subsequent releases. 5. Usage of S9(8) USAGE BINARY versus S9(9) USAGE BINARY avoided double precision arithmetic when using TRUNC(OPT). 6 With new compilers changing all USAGE BINARY and USAGE COMP fields to USAGE COMP-5 should allow use of TRUNC(OPT) safely. In another posting I will note some changes to the COBOL compiler that could be done to improve efficiency and allow more efficient code to be written. > >We were able to expand our ECSA safely about 6 months later. > >Regards >Bruce Hewson > >-- >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
USAGE BINARY in COBOL was Re: SLIP trap for "wild branch"?
On 30 Aug 2006 17:08:37 -0700, in bit.listserv.ibm-main you wrote: >In ><[EMAIL PROTECTED]>, >on 08/30/2006 > at 07:38 AM, "Chase, John" <[EMAIL PROTECTED]> said: > >>AFAIK our "shop standard" back in VS COBOL II days was to specify >>TRUNC(BIN) for all "online" programs. I think most "address-type" >>fields were specified PIC S9(8) COMP, so the "decimal limitation" got >>hit a lot sooner. > >Doesn't COBOL allow declaring variables as binary? It used to. > The devil is in the details. The address fields could have been declared as USAGE POINTER. The use of USAGE BINARY (or COMP) does not mean that PICTURE is ignored. Compile option TRUNC(STD) means that all operations to the field will cause truncation based on picture. Option TRUNC(OPT) means that operations involving mixed usage (fields that are binary and fields that are display or packed decimal with literals being assumed USAGE BINARY) will be truncated according to PICTURE as will a DISPLAY of the field. Compile option TRUNC(BIN) means that PICTURE is used to determine whether the field is a half-word, word or double word and truncation is at the word boundary. -- 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: Another BIG Mainframe Bites the Dust
On 7 Sep 2006 02:49:53 -0700, in bit.listserv.ibm-main you wrote: >This bit stood out the most for me: > >"According to Sangho Yoon, director of the information strategy team at >Samsung, the decision to move off Big Iron was strictly financial." > >Moving their data warehousing and reporting systems to a superdome would make >some sense, but I would think reliability and security would be the top >priority for their operational systems. Depending on how well they were actually using the tools available, the statement may or may not be true. Reliability is based on the least reliable component. COBOL is required to generate code that correctly (if slowly) handles decimal correctly. Most packages are written first for Unix or Windows (SAP, Oracle financials, etc.). If the new environment allows passwords and user-ids greater than 8 characters, it may be perceived as more secure. It would be interesting to compare the CPU power and memory of the old boxes with their replacements. > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] >Sent: Thursday, September 07, 2006 10:47 AM >To: IBM-MAIN@BAMA.UA.EDU >Subject: Re: Another BIG Mainframe Bites the Dust > > >Maybe we won't know the details, the horror stories from administration >room. >However we will see if the company survive. There are companies which >got rid of mainframe and survived. It is possible. Sometimes it can be >profitable (less costly). > >Of course we can still "suspect" (or rather hope): what about security, >do they need more staff, maybe they were oversized very much (are YOU >oversized???), maybe their application was horribly inefective, maybe >they will have problems with EOQ/EOY, maybe they have problem with >response times, etc. -- 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: KOREAN INSURER RETIRES 7,000 MIPS MAINFRAMES
On 6 Sep 2006 14:02:35 -0700, in bit.listserv.ibm-main you wrote: > >Kopischke, David G. wrote: >> Greetings, >>Another interesting story today on SearchDataCenter. This is the >> biggest >> one I've read about so far. > > >Now comes the wait for the first hacker to break in and steal countless >millions of dollars of information :) Are mainframe Linux applications more secure than non-mainframe? Are z/OS mainframe Websphere applications more secure than the same functions in Websphere on non-mainframes or other operating systems? How secure are some of the old CICS applications against an attacker that knows CICS but not the individual applications? > >Mickey -- 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: FW: Another BIG Mainframe Bites the Dust
On 7 Sep 2006 10:13:38 -0700, in bit.listserv.ibm-main you wrote: >I hope that in their evaluation they considered the cost of feeding >20,000 chickens vs the cost of a few good mainframe sysprogs... La >sombra sabe! The release said the replacement was only 2 HP Superdomes or whatever their high end server is. > >Jon L. Veilleux >[EMAIL PROTECTED] >(860) 636-2683 > > > >I think a lot of it boils back down to what is needed. I'm not a huge >fan of server technology (20,000 chickens pulling a plow) but since we >don't run PROFS any longer, Locust notes is how I do e-mail. > >> snip -- 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: Another BIG Mainframe Bites the Dust
On 7 Sep 2006 06:43:00 -0700, in bit.listserv.ibm-main you wrote: >On Thu, 7 Sep 2006 10:20:21 -0300, Clark F Morris ><[EMAIL PROTECTED]> wrote: >> >> Reliability is based on the >>least reliable component. COBOL is required to generate code that >>correctly (if slowly) handles decimal > >what??? >Are you saying that COBOL code is unreliable? >that only cobol can generate decimal arithmetic? >that packed decimal arithmetic is slow? Ooops, I had too many brief statements. What I was trying to say was: 1. Even a mainframe can be insecure and unreliable if the facilities aren't used properly. The application has to use the security facilities in order to be secure. Thus the application (or the system installation process or the security administration) may be the least reliable component. 2. I am saying that COBOL is required to deliver the same results on decimal arithmetic regardless of platform and presence or absence of decimal arithmetic on that platform. Thus the HP Superdomes in this case should still get the same results in any given computation if compatible compiler options are chosen to match what was done on the z series. 3. Packed decimal arithmetic is much slower than binary on the z series. True decimal arithmetic becomes even more painful compute time wise on those platforms that don't have a decimal arithmetic instruction set. The greater speed of the other processors offsets this to at least some extent. > >Or something else? > -- 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
Recompiling everything was Re: In search of (false) rumor source
On 5 Sep 2006 18:30:31 -0700, in bit.listserv.ibm-main you wrote: >>let's see "LE/COBOL" has been available for what 15 years now, it's time to >>bite the bullet and get off of >cobol II and vs cobol >period. end of comment. > >So! You're ready to come out to my shop. >Ready to re-compile everything. >Test it. >Fix the incompatibilities. >For free? >Gee. Where where you during Y2K? Burroughs which became the A series division of Unisys still will require recompilation of programs that use system facilities that are being upgraded. In the past, I believe they have required mass recompilation, sometimes because of underlying hardware change. This does give an incentive for making certain you have the correct source. IBM may also require this on the i series but someone more familiar with that environment may prove me wrong. On the other hand Unisys is still supporting COBOL 74, the equivalent of OS/VS COBOL more or less. VS COBOL II, release 4 and later are COBOL 85. > >When in doubt. >PANIC!! > -- 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: Another BIG Mainframe Bites the Dust
On 9 Sep 2006 22:02:52 -0700, in bit.listserv.ibm-main you wrote: >In <[EMAIL PROTECTED]>, on 09/08/2006 > at 06:11 PM, Bernd Oppolzer <[EMAIL PROTECTED]> said: > >>BTW, on older machines (not IBM) there were concepts like storage >>tags, which allowed to detect the use of uninitialized variables >>even for binary values. I don't understand why these concepts never >>reached the market. > >They did: Burroughs, now part of Unisys. RCA. Probably others as well. > What models and was it other than just data and instruction? -- 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: Another BIG Mainframe Bites the Dust
On 11 Sep 2006 09:01:16 -0700, in bit.listserv.ibm-main you wrote: >In <[EMAIL PROTECTED]>, on 09/10/2006 > at 09:09 AM, Clark F Morris <[EMAIL PROTECTED]> said: > >>What models and was it other than just data and instruction? > >Burroughs: B6500, B6700, B7500, B7800, etc. The tag bits constrained >how a word was interpreted for both data and instructions. > >RCA: CDP, 601. The tag bits were under programmer control and had no >effect on the interpretation of words, other than triggering an >interrupt and being testable. > I remember the 301, 3301 and 501. What was the 601? -- 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: Storage Tags (was: Another BIG Mainframe Bites the Dust)
On 12 Sep 2006 19:04:24 -0700, in bit.listserv.ibm-main you wrote: >In <[EMAIL PROTECTED]>, on 09/11/2006 > at 02:36 PM, "Patrick O'Keefe" <[EMAIL PROTECTED]> said: > >>The B5500 had similar structure and set of capabilities. > >There were major changes in architecture from the B5x00 to the >B6x0/B7x0 line. > >>It also had another processig mode - a string processing mode - >>where storage WAS directly accessable. > >One of the security problems that the B6500 fixed. > >>That suggests that the underlying architecture was quite different >>than what was presented to the user. > >I'm not sure what you mean by the underlying architecture. What >Burroughs documented was the format of the various control words, data >words and instruction syllables, along with the register set. Stream >mode was part of that. > >>We never learned aythig about string-mode processing (which was most >>likely not accessable from ALGOL) > >It was accessible from Extended ALGOL. IIRC Extended Algol was used as the Burroughs equivalent of Assembler for that series. -- 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: Static versus dynamic linking
On 15 Sep 2006 06:24:39 -0700, in bit.listserv.ibm-main you wrote: >Hi List, > >we are planning to go from static linking under IMS to dynamic linking, >COBOL transactions with DB2 access. The main reason for us is to avoid >relinking in case of modules are changed. >Are there any pitfalls, pros and cons about that? If you are going from modules with all of the subroutines linked in to modules where the subroutines are dynamically loaded at run time if needed and the subroutines are reentrant (Any COBOL program/subroutine starting with VS COBOL II can be reentrant and probably is by default), you may see a reduction in memory usage if the subroutines are in the same address space for multiple callers. You probably have to run tests to see what happens for your environment. My guess is the result would little difference but a definite impact on expectations when something changes because all callers will pick up the most recent version even if you don't want them to. > >e.g. more CPU cycles and thus higher Software costs for the subsystems? >Higher region recycling times in case of abends, Preload and LE >considerations? >What to do to avoid more I/Os? > >Thanks in advance. >Denis Gäbler. -- 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: VSAM space allocation in KB, MB, and RECORDS
On 16 Sep 2006 21:25:02 -0700, in bit.listserv.ibm-main you wrote: >I'm believe that for consistency with the same (irrational) choice made >for JCL allocation, "KB" and "MB" in IDCAMS defines are interpreted to >mean "KiB" and "MiB" (i.e., 2**10 and 2**20 Bytes). > >I usually allocate in RECORDS instead of KB and MB, so am not certain of >the rules for the latter, but suspect they may be similar - in which >case the allocation is based on effective available space on an initial >load of the dataset, which presumes that CI and CA free space will not >be used. I'm guessing you may be talking about a KSDS dataset with a CI >FSPC sufficiently large that your initial load would only utilize 24 KiB >per track. The problem with records is that if you want cylinder size CAs, you have no way of specifying it easily so for smaller VSAM files it is relatively easy to specify a secondary quantity that will result in sub-optimal CAs. > >The rules for calculating RECORD allocation for a KSDS used to be >something like > >records-per-CI = FLOOR( ( (DATA-CISIZE)*(1 - CI-FSPC/100) - >10)/AvgRecLeng ) > >records-per-CA = records-per-CI * FLOOR((CIs-PER-CA)*(1 - CA-FSPC/100)) > >CAs-ALLOCATED = CEIL( records-requested / records-per-CA) > >So, to calculate the number of tracks or cylinders required for the >requested number of records, you have to first know the CI and CA sizes >and average record length, and then de-rate that space for the CI and CA >free space that will be left unused during an initial data load. > >The "-10" in the records-per-CI comes from the minimum number of control >(non-data) bytes required in the CI, which occurs only if all records >happen to have identical length. If record lengths actually vary, more >than 10 control bytes will be used per CI. > >There used to a Red Book that described the details of logical record >storage within VSAM KSDS data sets. It predated, KB, MB, and record >allocation; but I extrapolated what I learned there to fit the behavior >I have since observed with the later space allocation forms. > >> rest snipped -- 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: IEHLIST LISTPDS in an SMS environment
On 18 Sep 2006 11:33:20 -0700, in bit.listserv.ibm-main you wrote: >ISPF Service LMMList can do it. > >Or you could write a little REXX to LISTDSI the dataset and pick up the >unit and volser. Then you could build your IEHLIST control card >dynamically and get the same output you are familiar with. Isn't IEHLIST long overdue for eliminating the need for specific volume information? It is aggravations like this that make zOS look dumb to those on other platforms. > >-Original Message- >From: CAPRON Romain [mailto:[EMAIL PROTECTED] >Sent: Sunday, September 17, 2006 11:50 PM >To: IBM-MAIN@BAMA.UA.EDU >Subject: IEHLIST LISTPDS in an SMS environment > >Hello, > >We're going to use SMS allocation in our z/OS 1.4 Production systems. >I have a little problem: a lot of our job batch use IEHLIST utility >LISTPDS command to retrieve the member list of some PDS. >With this utility, you have to put the right volser to make it >working... >But, with our SMS constructs, we won't know the volser and we don't want >to know it :-) We don't want to use the Guaranteed Space attribute... >Is there another way to generate the member list of a PDS in a batch >environment without giving the volser? > -- 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: HP and false emails
On 25 Sep 2006 03:41:05 -0700, in bit.listserv.ibm-main you wrote: >See "landmines" in http://www.isham-research.co.uk/dd.html > >The German adjective - not very politically correct - is "getürkt". > >I frequently mention my dear old HP41CV in the footnotes to the MIPS tables. >That's because >one of the things it's used for is to find landmines. > >In any given set of received MIPS tables there will be one or more >single-digit errors - >usually caused by one or more values being truncated rather than rounded. In >any other set, >the "errors" are often in different places. > >I recommend David Kahn's Codebreakers as an elementary text - wrapped up in >several good >narratives are some important lessons in signal security. Paraphrasing, >reformatting etc. > >His advice is to take as much care with the input as with the output. If HP's >ruse caught >anyone then it's their own fault. I believe that improper use was made of people's social security numbers and other personal information. From what I read in the Wall Street Journal, the investigators obtained phone records and other information under false pretenses. It was more than just phony e-mails. While this topic really isn't mainframe related it does point out that we need to be careful about who has access to production data and that an organization may need to rethink how it creates test data. If test data is normally a copy of production (or subset thereof), security needs to be as strong in the test environment as it is in production. It may also mean that test data has to have personal information scrambled. > >Grüße an Felix, übrigens. -- 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: Default System BLKSIZE for PDSE
On 5 Oct 2006 20:28:34 -0700, in bit.listserv.ibm-main you wrote: >In <[EMAIL PROTECTED]>, >on 10/05/2006 > at 07:58 AM, "McKown, John" <[EMAIL PROTECTED]> said: > >>4K physical and logical. Like VSAM LINEAR. Or a PAGESPACE. > >Do you know for a fact that those use a 4 KiB block size? > >>I sure wish that DFSMSdfp would support FBA. Or, even better, >>direct connection to a SAN via FCP the way that z/Linux can, perhaps >>as emulated FBA. > >So did a lot of other people, 3 decades ago. IBM rejected the >requirement. :-( > >When was the last attempt? Is it too soon to try again? > I submitted a requirement to the SHARE storage management project within the past 4 years that didn't attract much interest but I was unable to attend the SHARE conferences so personal lobbying might help. -- 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: Another BIG Mainframe Bites the Dust
On 12 Oct 2006 05:30:38 -0700, in bit.listserv.ibm-main you wrote: >In ><[EMAIL PROTECTED]>, >on 10/10/2006 > at 10:26 PM, Ted MacNEIL <[EMAIL PROTECTED]> said: > >>I moved from my Bell BlackBerry account to a YAHOO using POP3, in >>June, because RIM re-engineered their support making a REPLYTO >>mandatory for all BlackBerry ids. > >And you can't figure out how to include > >Reply-To: IBM Mainframe Discussion List <[EMAIL PROTECTED]> > >when you post to IBM-MAIN? > Given that the majority of the messages that I reply to do not have the reply to set that way but rather are like Ted's, I suspect that it would be easier to have the listserv set it if it can. I read the newsgroup using Agent 4.0 and may well have an equally bad reply-to. -- 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
(fwd) Re: How does Citrix run it faster? was Re: Microfocus COBOL 3.2.43 (16bit)
The exchange below shows one way our world may evolve. It does bring up the question of whether IBM is shooting itself in the foot with its z series pricing. It has to be bad when it is worth while to write a VSAM replacement, etc. for use on Linux. On Sat, 23 Dec 2006 00:48:05 -0600, in comp.lang.cobol "P. Raulerson" <[EMAIL PROTECTED]> wrote: > >"Clark F Morris" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >> On Fri, 22 Dec 2006 18:54:55 -0600, "P. Raulerson" >> <[EMAIL PROTECTED]> wrote: >> >>>Your guess would be partly right - I support Mainframe (z/OS, z/VM, >>>zLinux), >>>AIX, Linux, iSeries (OS/400, i5OS, Linux) and several varieties of >>>Windows, >>>including that blasted 64bit variant of Server 2003 that gives me >>>heartburn. >>>In fact, our entire enterprise (about 350 people geographically scattered >>>over 25 sites) runs on Citrix served up from servers here in Austin. >>>Citrix >>>would be a bit expensive for what this chap wants, but it saves us a ton >>>of >>>money ,and an incredible number of support hours. >> >> Are you the sole support person and if so how? Z/OS alone is normally >> a two or three person job. > >There are five of us, and we don't have a large z/OS footprint right now. We >have moved a lot of stuff to zLinux, and in the process would up writing >3270 terminal drivers, a VSAM equivalent, process management, transaction >control, and so forth. Took about three years to do it all, but it was >worth it. The end result is we can do an awful lot of processing awfully >fast for a very small amount of money. lets us undercut the competion quite >handily. We tend to use z/VM to handle the zLinux instances, and once setup, >z/VM is a low maitenance type of thing. > >I'm also not to oround to find and hire good consultants if I happen to be >getting over my head either. ;) But with mainframe hardware, our stuff just >runs and runs and runs and runs and... well you get the idea. We control >cost this way. >>> >>>That's a corollary duty by the way, along with phone systems, network >>>design, security, and second assistant cook and bottle washer too I >>>suppose. >>>I am best at being your everyday Sr. Software Engineer. That's in COBOL, >>>C, >>>Java, Ada, Assembler, and assembly language for a few other processors. I >>>dabble in Visual Basic, RPG, and a half dozen other languages just because >>>they interest me. >>> >>>(Yep: I work for good people and I have a great job, when it does not wear >>>me down to a nub... :) >>> >>>To be fair though, I did sound arrogant, and that was not intended. I >>>apologize for that. It is just that I tend to solve these kinds of issues >>>several times per quarter, and, if this case is what I think it is, using >>>a >>>centralized VM to deal with this is probably a very good idea. >>> >>>On the other hand, to me, you sound like a PC person who has little >>>experience on other platforms. Bet you would argue that running Microsoft >>>Office on standalone machines is faster than running it under Citrix. >>>(Hint: it is much faster under Citrix. :) Where are you coming from, and >>>am >>>I anywhere close to right? :) >> >> How does Citrix run Office faster? > >Basicaly most Windows programs load one 'read only' code segment, and then a >read/write data segment into memory for each user. When Word loads for the >first user, it is about the same speed as on a local workstation, but the >second, third, and subsequent users usually see Word load in less than >second. It;'s a dumb thing, but I can bring up 20 or 30 instances of Word as >fast as I can click the mouse on it. > >Now the other thing is that Windows machines spend so much time managing >displays, that processor intensive stuff, like say, working on a big Word >document gets a littel shortchanged. A remote Citrix client is not usually >doing anything else but managing the screen, while the server is pretty much >just managing a memory buffer for that screen. No hardware manipulation or >driver required. The technology is quite fascinating and beyond that, >provides additional opportunities to enhance performance and response speed >to the users. Partly it is the same reason a 3270 screen almost always looks >'snappy' - he doesn't really do a whole lot till he has all the infomration >he needs to work on. > >The worst, the very worst Office application
Re: Systems Programming for 8 Year-olds
R.S. wrote: I had similar situation: My son had to prepare some presentation and he chose mainframes as the topic. I delivered some pictures (BTW:I spent almost 1 hour to find in Internet good picture of punched card, and next half when searching for BIG photo of z/990 !!!), some "funny" facts - like "mainframe is bigger than fridge ...and there is refrigerator inside!", or "in the past mainframe had 64kB of RAM. Yes, it's 1000 times less than the oldest PC in your class." Another : "mainframes are vry expensive, entry level solutions is over 1M$, and believe me: no game will run on it". Since there is a version of Star Trek on either the CBT tape or the MVT mods tape and a game actually became a production program in one shop as a means of getting sales people comfortable with the computer, I don't believe you. Granted these were for a standard 3277 or 3278 so the graphics weren't wonderful but there were games. Last but not least: I gave him some requsites: the card, the tape, and Bus&Tag cable (half meter with the plug). The last thing wasn't good idea: boys used them as a club (weapon) and were fighting. Software is safer. -- 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
