Re: Mainframes.. Extinct or still going strong ?
F wrote: We use IMS and DB2 on z/OS today and was wondering if we should consider moving to distributed systems like Oracle or SQL Server. Reason being, we are concerned about mainframe skill sets on IMS and DB2. Also the news around many systems moving away from mainframes keeps us wondering what to do. This seems funny to me since my recent (past 5-10 years) experience with folks claiming Oracle and SQL Server skill sets reinforces my opinion that DB2 on z/OS is still on rock solid ground. There is a truly scary lack of SQL Server skill sets in today's marketplace and not much in terms of Oracle skill sets either. Nothing to bother writing home about anyway. If any company is considering a move from z/OS and DB2 to SQL Server or Oracle I would truly want to know about it. -- Tom Schmidt -- 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: WLM Subsystem Type TCP
Hi Barbara http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.halz002/ziipsec.htm might be a starting point. jan - Oorspronkelijk bericht - Van: Barbara Nitz [mailto:[EMAIL PROTECTED] Verzonden: maandag, mei 26, 2008 02:36 PM Aan: IBM-MAIN@BAMA.UA.EDU Onderwerp: WLM Subsystem Type TCP By chance I discovered that there is now a WLM subsystem type called TCP (not mentioned in my 1.8 planning book), apparently used for offloading IPSEC stuff to ZIIPS, which we don't have. The enclaves are named TCPENC01 and there is one per IP stack. And yes, as they are not defined here, they're running in sysother. :-( Does anyone have experience with these enclaves and has a good idea for a WLM goal to start with? Thanks and regards, Barbara Nitz -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger -- 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: SDSF slow after migration to z/OS 1.9
See PK52910. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2
On Fri, 23 May 2008 04:25:10 -0400, David Cole [EMAIL PROTECTED] wrote: Hi, I have a process that submits up to a couple of hundred jobs for execution. I require that these jobs execute in the same order in which they were submitted. For decades I have accomplished this by assigning all of the jobs to a specific job class and then insuring that there was never more that one initiator that had that job class assigned. I am now running at a new data center. (Guess where...) And I have just discovered that my jobstream is running out of sequence. For some reason, my single-threading initiator is selecting jobs from the input queue out of sequence. Is there an official way to enforce job execution sequencing? TIA Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For the longest time before we moved the application to a scheduler we had a similar situation where we had one jcl deck that contained hundreds of jcls within the one deck. We also had the need to run these in the order they were submitted and we got around this by simply setting the priority of all input jobs to be the same priority ($TJ1-,P=10) which meant that all the jobs ran in the order we needed. It could be further qualified to specify a job mask $tJ1- ,JM=MYJOBS* if needed. It wasn't ideal but it worked for us for several years. Best regards, Gil. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
WLM Subsystem Type TCP
By chance I discovered that there is now a WLM subsystem type called TCP (not mentioned in my 1.8 planning book), apparently used for offloading IPSEC stuff to ZIIPS, which we don't have. The enclaves are named TCPENC01 and there is one per IP stack. And yes, as they are not defined here, they're running in sysother. :-( Does anyone have experience with these enclaves and has a good idea for a WLM goal to start with? Thanks and regards, Barbara Nitz -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger -- 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: 80-Column Minds (Was: SMP/E question)
... could you not just use RECFM=V and send 84 byte JCL and 208/212 LRECL SYSIN Data? I assume so, but I never tried to do that. Using in-stream data sets with more than 80 bytes per card was an extension to an existing program (that used to require only 80 bytes of in-stream data) which used two separate DCBs to write the JCL and the in-stream data. I just kept the one that was handling the actual JCL as FB-80 and changed the one that was handling the in-stream data to V-whatever. It may have been the case that for some reason my SVS 1.7 HASP 4.0 mods to make all this work required the use of a RECFM=F[B] DCB for actual JCL. I do not remember that being the case, but lots of this is very hazy now, so I can't really say. -- WB -- 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
SDSF slow after migration to z/OS 1.9
Greetings listers We're facin a problem we met after migration to z/OS 1.9. It's with SDSF. After migration we saw that SDSF is slow in response, expecially in displaying output classes. In some cases is VERY slow even if CPU is quite far from 100%. Did anyone encounter the same problem after migration to z/OS 1.9 ? Any new (or old) parameter to check ? Thank you in advance Massimo Scarpa -- 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: WLM Subsystem Type TCP
Jan, I had found that book myself, but thanks. I did mention that we are 1.8 (not 1.9), we do NOT have ZIIPs, and my IP guy tells me that we are NOT using IPSEC. Besides, the book doesn't give me a good dstarting point for defining a goal. Response time? Another execution velocity? The only thing it talks about is importance, which makes me thing that I shouldn't put SYSSTC as a service class there (that is where part of the enclaves execute and where I have put the actual TCPIP address spaces (IP stacks). Best regards, Barbara -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger -- 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
