Re: Barbaras (mini-)rant
- snip - I'm with Jim on this. I was a contractor in the mid to late '90's and came across the early TCPIP stack, written in PASCAL and ported from VM. As I recall it performed OK, and had some quite advanced features like VIPA which was the subject of another recent thread. - snip - I installed TCPIP 2.2 or 2.2.1 in November 1992. It was written in PASCAL(/VS?), there were two subsystems: TNF and VMCF (virtual machine communication? facility) because it was a port from VM. Dataset names were hardcoded, so I had problems with our dataset naming standards, messages had no message ids. Somehow I do not remember VIPA at that time, I think it came in 3.3 or 3.4. I believe to remember it was possible to change the MAC address on the 3172. In the release 3.1 or 3.2 there were two FTP servers, one written in C and one in PASCAL(/VS?). Zaromil -- 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
SMFPRM
Hi to you all, in the SMFPRM I found the following: SYS(NOTYPE(14:19,62:69,99),EXITS(IEFU83,IEFU84,IEFACTRT, IEFUSI,IEFUJI,IEFU29),NOINTERVAL,NODETAIL) /* WRITE ALL EXCEPT DATA MANAGEMENT RECORDS, TAKE EXITS. */ What type of events are not being logged ? Who, when, type of access to datasets are events? Thanks! -- Cumprimentos, Luís Correia -- 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: SMFPRM
Luis, You should become familiar with the z/OS MVS System Management Facilities (SMF) manual, SA22-7630-10 for V1R6.0-V1R7.0, http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2G251/ I presume you are asking about which types the statements you show select. Checking on NOTYPE revels that you will store all records *except* those listed, which are 14 to 19 (note the significance of the :), 62 to 69 and 99. The excluded record types are, copy and pasting from the Contents page: Record Type 14 (0E) -- INPUT or RDBACK Data Set Activity Record Type 15 (0F) -- OUTPUT, UPDAT, INOUT, or OUTIN Data Set Activity Record Type 16 (10) -- DFSORT Statistics Record Type 17 (11) -- Scratch Data Set Status Record Type 18 (12) -- Rename Non-VSAM Data Set Status Record Type 19 (13) -- Direct Access Volume Record Type 62 (3E) -- VSAM Component or Cluster Opened Record Type 63 (3F) -- VSAM Catalog Entry Defined Record Type 64 (40) -- VSAM Component or Cluster Status Record Type 65 (41) -- Integrated Catalog Facility Delete Activity Record Type 66 (42) -- Integrated Catalog Facility Alter Activity Record Type 67 (43) -- VSAM Catalog Entry Deleted Record Type 68 (44) -- VSAM Catalog Entry Renamed Record Type 69 (45) -- VSAM Data Space Defined, Extended, or Deleted Record Type 99 (63) -- System Resource Manager Decisions QED I'm not quite sure what you mean by your second question but now you have a good pointer to where to find the information, I expect the answer is there. Chris Mason - Original Message - From: Luis Correia [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, 29 March, 2006 1:03 PM Subject: SMFPRM Hi to you all, in the SMFPRM I found the following: SYS(NOTYPE(14:19,62:69,99),EXITS(IEFU83,IEFU84,IEFACTRT, IEFUSI,IEFUJI,IEFU29),NOINTERVAL,NODETAIL) /* WRITE ALL EXCEPT DATA MANAGEMENT RECORDS, TAKE EXITS. */ What type of events are not being logged ? Who, when, type of access to datasets are events? Thanks! -- Cumprimentos, Luís Correia -- 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: Bringing the fun back to z/OS - new course
A couple thoughts here, since I think Steve was talking about letting IBM know of these issues. First a point Barbara made: We are in the process of moving the UNIX apps to Linux under VM, where they can use the other type of processors and save us a lot of software costs (BMC is killing us, followed by CA.) IBM made a strategic decision several years ago to enter into direct, professional competition with BMC and CA. I would advise any customer to weigh their options now that there is heightened, healthy competition. That's not particularly vendor specific, actually. If you're an IBM tools/utilities customer then I would advise you to periodically compare with other vendors. In other words, it works both ways. One thing we've discovered is that terms and conditions often matter most, including license restrictions, capacity upgrade charges (tier levels, MIPS on the floor rules), etc. We've tried very hard to introduce more rationality into mainframe software pricing and terms. (Which is interesting, because the other platforms seem to be getting less rational with each passing day. :-)) With respect to Patrick's comments, WebSphere Application Server/Java is certainly not IDMS/ADO (for example) from a resource utilization point of view. A modest two-way CP-only 31-bit-only system is simply not going to be delivering very high WebSphere volumes, I'm afraid. Unless your WebSphere Application Server workload is trivial, please do one of two things: (1) get a zAAP (for WAS z/OS); (2) get an IFL (for WAS Linux). It's frankly bad *finance* to run (much) WAS without either of these two options. Spend money to save a lot more money. With either one of these two approaches mainframe WAS becomes not just affordable but, in numerous situations, the *most* cost-effective J2EE platform. My personal favorite is zAAP, but please choose at least one of these two avenues. Yes, WAS loves storage. But we're now in the era when even z800s come with minimum 8 GB, so the times they are a-changin'. (IBM saw these new workloads coming years ago and declared that everybody would have some generous storage even in the base configuration. I think it was one of the smarter things we've done.) Wasteful? Maybe. But IBM just cut the memory price (again, with the System z9), and we're now in the era when programmers aren't counting bytes (or even kilobytes) like they used to. Steve asks in reply about the IBM HTTP Server for z/OS -- is that lighter? Answer: absolutely. It's mostly I/O work, and allegedly mainframes handle that. :-) I'm generally not concerned about workload impact of HTTP serving, even on modest systems. If you're looking to get your feet wet with HTTP serving, a good match is WebSphere Host On-Demand hosted on z/OS. It's very quick and easy to set up, it's very light workload, it's frankly the best place to host Host On-Demand, and I guess you could say it's step zero on the road to WAS. There are other candidates for z/OS HTTP serving, but that's one of my favorites. Do note that the first Web server in the world outside Switzerland was installed on a Stanford mainframe -- a long time before any still extant operating system got a Web server. So HTTP serving on mainframes isn't exactly new, and you'll have lots of company if (when, I hope) you decide to join the club. Lastly, I think there's an implication that workloads in USS cannot fit into WLM service classing, goals, etc. in order to manage together with batch and other classic workloads. I hope nobody is saying that, because it's certainly not true. z/OS and WLM will manage all work, including USS-based work, as you tell it. If your system is too small to meet or exceed all goals at peak, that'll still be true regardless of the *type* of work you throw onto the system. WebSphere z/OS is spectacularly plugged into WLM -- it works really, really well, at least for the past three versions that I'm more familiar with (5.0+). But if I'm trying to suck an elephant through a straw and want the elephant to more or less retain its shape, well... :-) Kudos on this effort, Steve. It sounds really interesting. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3380-3390 Conversion - DISAPPOINTMENT
In [EMAIL PROTECTED], on 03/29/2006 at 12:35 AM, Ron and Jenny Hawkins [EMAIL PROTECTED] said: No I'm not. Then where do you get the idea that the number 256 has anything to do with text record sizes? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Barbaras (mini-)rant
In [EMAIL PROTECTED], on 03/28/2006 at 02:54 PM, Patrick O'Keefe [EMAIL PROTECTED] said: I suspect the rewrite story is apocryphal. Possibly the details are. But it is a fact that IBM ported a Pascal-based TCP/OP from VM to MVS, including a simulated VMCF. It is also a fact that OS/390 2.5 shipped with a Unix-based TCP/IP. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Barbaras (mini-)rant
In [EMAIL PROTECTED], on 03/28/2006 at 12:00 AM, Ted MacNEIL [EMAIL PROTECTED] said: I heard a story, many aeons ago, that the original TCP/IP for ESA/OS390 was a direct port from VM, written in PASCAL. And, it was a PIG! Correct, including simulation of VMCF, which in the VM world has been obsolete for lo these many years. USS Unix. This made it to OS/390 V2.5, I believe. Correct. Alas, we were not allowed to convert off of TCP/IP V3R5, which ran just fine at least through OS/390 V2R9. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CICS down after transaction exec wait macro.
In [EMAIL PROTECTED], on 03/28/2006 at 03:28 PM, Jorge Arueira Campos [EMAIL PROTECTED] said: Issuing a wait macro in a CICS transaction, in the main task, is forbidden. Why no have a protection for not down the CICS ??? It would be expensive to enforce the various rules that a transaction should follow. However, usually issuing a WAIT will only cause performance problems. Is necessary open a call in support IBM for this problem ??? Only if it's an IBM product issuing the WAIT. Also, keep in mind that this applies only to a WAIT in the CICS main task. The current CICS has support for a transaction to request execution in a subtask. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CICS down after transaction exec wait macro.
In [EMAIL PROTECTED], on 03/28/2006 at 09:04 PM, Chris Mason [EMAIL PROTECTED] said: One interpretation of what Shmuel says is that it is still something a CICS transaction programmer shouldn't even think of doing. Is there another interpretation[1]? But note that the it in question was doing the WAIT in the CICS main task; the current CICS allows a transaction to request execution in a subtask. [1] That's a separate question from whether you agree with what I wrote. IAC, it's not my dog. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Legality of z/OS 1.5 in 31-bit mode under z/VM at D/R Test
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Skip Robinson Whoa. Was this a trick question like, 'Are you allowed in California to marry your widow's sister?' ? Bimodal Accommodation absolutely stopped with z/OS 1.4. It does not bear on the original query. It was not intended as a trick question. Currently running z/OS 1.5 on a G5 machine, with upgrade to a z/Box scheduled *after* our next D/R test. Our D/R provider has informed us that they will be able to furnish only a z/Box for our next D/R test; hence the question, given the (apparent) capability of z/VM to define a pre-z/Box virtual machine. Though it might be nice to recover to a 64-bit operating environment, we perceive the purpose of the D/R test is to recover the existing environment. We currently intend to use the D/R technique to migrate to the new z/Box when it gets installed here. -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: Barbaras (mini-)rant
In a message dated 3/29/2006 2:58:30 A.M. Central Standard Time, [EMAIL PROTECTED] writes: In the release 3.1 or 3.2 there were two FTP servers, one written in C and one in PASCAL(/VS?). Same recollection and that since TCP was shipping statically linked VS/PASCAL with it's code violated packaging rules and couldn't be order via Software Manufacturing(PDO,S*/PAC). -- 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: Anyone Using IBM 3592, Sun/STK 9940, or Sun/STK T10000 Cartridges for HSM ML2?
For an explanation of tape recall takeaway, click on the following link. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2S630/2.3. 3.1.1?SHELF=EZ2ZO10EDT=20040711204223CASE= -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark van der Eynden Sent: Tuesday, March 28, 2006 11:20 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Anyone Using IBM 3592, Sun/STK 9940, or Sun/STK T1 Cartridges for HSM ML2? On Tue, 28 Mar 2006 16:01:03 -0600, Friske, Michael [EMAIL PROTECTED] wrote: Is anyone using IBM 3592, Sun/STK 9940, or Sun/STK T1 cartridges for HSM ML2? If so, have you had any issues (slow recall times, recall tape takeaway, recycle, audit, duplexing, or other)? We've got 9940s behind a VSM... Every now and then someone tries to call a recall from near the end of a tape 'slow', but I think if you do the maths, you fill find there is a heck of a lot of data being read to get to a file near the end of the tape. You do need to make the HSM MOUNTWAITTIME larger than the default, both for this reason and the possibility that the first mount may be for a duplexed pair that is offsite and needs to time out in order for the available tape to be requested. BTW what's 'recall tape takeaway'? Mark -- 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: SMFPRM
Luis, Thank you for the private thank you in which you indicated that your second question was what type of events were being logged. As I mentioned, it is every type of SMF record *except* those excluded by the NOTYPE specification. You will see very many types described in the SMF manual - starting with the contents description for Chapter 13[1]. However you should be aware that you may have products logging SMF records which are not described here. The point is that SMF, as you can see from other parts of the manual, has an API for logging system management records. I believe the rule is that IBM is allowed to use the numbers 0 to 127 and 128 to 255 are for customer/vendor use. If a vendor creates SMF records it makes sense that it would be possible to select the SMF record type number so that clashes can be avoided. Here's a little point regarding SMF I used to promote during classes: If you are keen to produce your own SMF records and you are in a NetView environment, NetView supplies a tool which provides for just this - in a very simple way. The VPDLOG command, while appearing to be specific to vital product data, is actually quite general. [1] You will find that often in the SMF manual the type is mentioned in the contents but when you take a look you will find a reference to the product manual, for example, NPM. The product manual will have the full description of the SMF record. Chris Mason - Original Message - From: Luis Correia [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, 29 March, 2006 1:03 PM Subject: SMFPRM Hi to you all, in the SMFPRM I found the following: SYS(NOTYPE(14:19,62:69,99),EXITS(IEFU83,IEFU84,IEFACTRT, IEFUSI,IEFUJI,IEFU29),NOINTERVAL,NODETAIL) /* WRITE ALL EXCEPT DATA MANAGEMENT RECORDS, TAKE EXITS. */ What type of events are not being logged ? Who, when, type of access to datasets are events? Thanks! -- Cumprimentos, Luís Correia -- 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: Legality of z/OS 1.5 in 31-bit mode under z/VM at D/R Test
Chase, John wrote: Since one can specify MACHINE=XC and define a 31-bit-only virtual machine, any thoughts on whether it would it be legal (in the US) to IPL z/OS 1.5 (effectively in ARCHLVL=1 mode) on that virtual machine for D/R testing if the real machine is a z/Box? There have been several responses. Amazingly, none of them address the most fundamental issue of all. Your premise is wrong. z/OS does *not* support ESA/XC architecture. It supports only z/Architecture and ESA/390 architecture! If you try to IPL z/OS (any release supporting ESA/390 architecture) in a guest defined with MACHINE XC, you will receive: HCPGIR450W CP entered; disabled wait PSW 000A 0019 which is IPL-speak for a program check at startup. If you want to run z/OS 1.5 in ESA/390 mode under a VM guest on a box that implements z/Architecture, you will need to run it under VM/ESA 2.4, either first-level (native) or second-level under z/VM. It works!!! Not sure if VM/ESA 2.4 is still supported though... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: Barbaras (mini-)rant
Ed Finnell wrote: Same recollection and that since TCP was shipping statically linked VS/PASCAL with it's code violated packaging rules and couldn't be order via Software Manufacturing(PDO,S*/PAC). Doesn't anyone change subject lines anymore? This thread has absolutely nothing to do with Barbaras (mini-)rant! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: Removed 3480 drives - question
The DEVTYPE in the catalog is the actual value not the esoteric. The only time there is an esoteric is if the catalog entry is created via a Catalog Command (ie: IDCAMS/IEHPROGM/etc that is true, since the DEFINE NONVSAM or CATLG command only knows the esoteric or generic provided in the command or a JCL DISP=CATLG in an IEFBR14 Step) Not true. Even an IEFBR14 must allocate a device, so it knows the real device type From the JCL manual If you have 3490 Magnetic Tape Subsystem models A10 and A20 defined to your system and you use one of the IBM-generated group names SYS3480R or SYS348XR, the system overrides the device type retrieved from the catalog with a device from the esoteric device group. SYS3480R and SYS348XR select any drive capable of reading a 3480 cart (XR is for IDRC-compressed tapes). So every time you refer to a cataloged dataset on a 3480, you have to provide a override of UNIT=SYS3480R or SYS348XR. the other alternative is to recatalog all of the 3480 tapes to a device type of 3490. There were some utilities to do so. IBM may have provided one and there were probably freebies to do it as well. -- Bruce Black Senior Software Developer Innovation Data Processing -- 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: Wonder why IBM code quality is suffering?
They're not. The latest matrix price I saw for this position was $50. Ennh, thank you for playing. The $50 goes to the pimp, who turns around and maybe coughs up $35 to a W-2 who's paying for his own health care, etc. I guess I interpreted matrix price differently. Obviously $50/hour full time direct employee (with benefits) is substantially different than $50/hour paid to a middleman firm. I assumed the former from the original poster. Perhaps a bad assumption. But I made the assumption because $50/hour paid to a contract firm wouldn't seem to be sufficient to obtain qualified U.S. local programming talent. My wild guess is that the position did not get filled at $35/hour sans benefits. In other countries would $35/hour be sufficient to recruit programming talent? Maybe, but that's only the numerator. You then have to adjust for productivity and quality, and those aspects could vary dramatically depending on the country. I happen to believe that quality programmers are true professionals, and professionals are not easily swappable. I think the better development managers agree with me. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Tape Encryption
In the IBM-MAIN archives (from about August or September, 2005) there should be a list of tape encryption products posted. (Search on tape encryption and it should be pretty easy to spot.) There were also some follow-up posts noting CA-BrightStor and OpenTech as additional vendors in that same category. I tried to include some commentary in those messages about general principles for tape encryption, so that might be helpful, too. There will be more products in 2006, so I might need to update the list again later this year. But 2005 was a very big year for tape encryption due to some urgent needs, particularly in the financial services industry. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS Change Management / Change Control Procedures
Doc, Are you looking for programs and code or discipline and procedures? I'm not sure if this helps, but The Visible OPS Handbook (http://www.tripwire.com/practices/visops.cfm) by Kevin Behr, Gene Kim and George Spafford lays out a superb framework for change and configuration management. Is that the sort of information you're looking for? Dave Froberg I'm trying to look up some sample change management / change control procedures for operating system and system/subsystem utility changes, but I'm not having much luck in a Google search (or a search of IBM-MAIN, for that matter). I'm pretty sure they'd have to be more rigorous than application CCPs, if only for the wide-ranging impact those changes can have. Does anyone out there have some sites/samples/examples of workable operating system CCPs? If so, I'd appreciate a copy or a link. Many thanks. Doc Farmer -- 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: Legality of z/OS 1.5 in 31-bit mode under z/VM at D/R Test
Since one can specify MACHINE=XC and define a 31-bit-only virtual machine, any thoughts on whether it would it be legal (in the US) to IPL z/OS 1.5 (effectively in ARCHLVL=1 mode) on that virtual machine for D/R testing if the real machine is a z/Box? I don't see why not, it is legal to us the bi-modal support mod which allows you to run 31-bit mode at a DR site as long as you want. (the 6 month limitation does not apply to DR). Bimodal Accommodation absolutely stopped with z/OS 1.4. It does not bear on the original query. Right, z/OS Bimodal Migration Accommodation is/was available only up through z/OS 1.4. When running z/OS 1.5 (at least not under z/VM) on a z/Architecture system it has to IPL in 64-bit mode -- that's a technical requirement at least. z/OS 1.5 can run in 31-bit mode on a pre-z/Architecture system. (It's the last z/OS release able to do so.) I very confused, though, so maybe John Chase can post a follow-up. I understand the configuration: - z/VM (with a 31-bit VM defined) - z/OS 1.5 (IPLing in 31-bit mode) - z/Architecture system Effectively z/VM is acting as the bimodal accommodation here. I assume z/OS 1.5 will IPL this way (and won't figure out what the real iron is underneath), but I don't know that for sure. What I'm really missing is what this z/OS VM is supposed to be D/R backing. Is it intended to be a D/R environment to stand in for a pre-z/Architecture system running z/OS 1.5 in 31-bit mode? In other words, is the primary system (for this z/OS) a pre-z/Architecture system? There's an end of service date coming up on z/OS 1.5 (and prior) of March 31, 2007, so another question would be whether it makes sense to create this configuration with t-minus 12 months of service life. I don't think there's a legal impediment, but I would get a second, formal opinion. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Systems Programmer Levels Justification
Grab a Messages and Codes manual. Count the number of resolutions that say something along the lines of Contact your SYSTEMS programmer vs. Contact anyone else. :) Perhaps a little bitterness seeping through here. I have a DBA that stops working on anything once he finds that phrase in the manual. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Desi de la Garza Sent: Tuesday, March 28, 2006 2:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Systems Programmer Levels Justification MVS Listers, We are in the process of justifying the requirement of having multiple levels of SysProg job titles depending on experience and knowledge. At the same time provide management with information as to why SysProgs are higher salaried than application programmers. They are at a loss as to why that is. Weird that they do not question why a network tech makes more than the applications also. Can someone guide me to where I may be able to locate such info? Thanks, Desi de la Garza Systems Programmer Bexar County Information Services [EMAIL PROTECTED] -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html # Attention: The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. # -- 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
FLEX-ES
.. mainframe malarky .. There's no money in it. And I'm not the only one pissed at IBM's legal team - they seem to have adopted a policy of making swimming along with them as difficult as possible. As far as I'm concerned, the market is going below critical mass. I'll do a page or two for the next one, but I suspect that will be it. There's always Gartner. http://armadgeddon.blogspot.com/2006/03/does-gartner-podcasting-from-ibm.html -- Phil Payne http://www.isham-research.co.uk +44 7833 654 800 -- 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: Systems Programmer Levels Justification
Also, go to the IEFSSN member of PARMLIB and check if there are any applications programmers that know anything about how to set up/configure any of them (or even what they are). Then throw in Workload Manager, VTAM, and all your (other) ISV products, too. Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Klein, Kevin Sent: Wednesday, March 29, 2006 10:33 AM Grab a Messages and Codes manual. Count the number of resolutions that say something along the lines of Contact your SYSTEMS programmer vs. Contact anyone else. :) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Desi de la Garza Sent: Tuesday, March 28, 2006 2:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Systems Programmer Levels Justification MVS Listers, We are in the process of justifying the requirement of having multiple levels of SysProg job titles depending on experience and knowledge. At the same time provide management with information as to why SysProgs are higher salaried than application programmers. They are at a loss as to why that is. Weird that they do not question why a network tech makes more than the applications also. -- 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: Legality of z/OS 1.5 in 31-bit mode under z/VM at D/R Test
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Timothy Sipples [ snip ] Right, z/OS Bimodal Migration Accommodation is/was available only up through z/OS 1.4. When running z/OS 1.5 (at least not under z/VM) on a z/Architecture system it has to IPL in 64-bit mode -- that's a technical requirement at least. z/OS 1.5 can run in 31-bit mode on a pre-z/Architecture system. (It's the last z/OS release able to do so.) I very confused, though, so maybe John Chase can post a follow-up. I understand the configuration: - z/VM (with a 31-bit VM defined) - z/OS 1.5 (IPLing in 31-bit mode) - z/Architecture system Effectively z/VM is acting as the bimodal accommodation here. I assume z/OS 1.5 will IPL this way (and won't figure out what the real iron is underneath), but I don't know that for sure. Ed Jaffe responded that that won't work (gets a disabled wait state early on), and since he's in the business of trying out those kinds of things I believe his response can be accepted as definitive. What I'm really missing is what this z/OS VM is supposed to be D/R backing. Is it intended to be a D/R environment to stand in for a pre-z/Architecture system running z/OS 1.5 in 31-bit mode? In other words, is the primary system (for this z/OS) a pre-z/Architecture system? Yes. There's an end of service date coming up on z/OS 1.5 (and prior) of March 31, 2007, so another question would be whether it makes sense to create this configuration with t-minus 12 months of service life. We perceive it as a SOX requirement to recover our current Production system at D/R. Though we are currently upgrading to z/Architecture hardware (and z/OS 1.7), we will not be there before our next D/R test. I don't think there's a legal impediment, but I would get a second, formal opinion. Has been requested. -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: Systems Programmer Levels Justification
At the same time provide management with information as to why SysProgs are higher salaried than application programmers. They are at a loss as to why that is. Weird that they do not question why a network tech makes more than the applications also. I think many sysprogs are also application programmers, or started out in that position. I spent 9 months as a code warrior before switching to systems. I've coded quite a few assembler, cobol and cics apps in my position as a sysprog. Also, I sometimes debug applications when a programmer needs such assistance, ie stg violations. App programmers here don't have the knowledge to read dumps and xpediter doesn't always catch them. Dave Low -- 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
z/OS 1.7 and Large Sequential Data Set Offering
Actually, the bit is used by VSE. But it's use was never recorded in any OS mapping of the Format-1 DSCB. The DOS footprint bit? It _was_ mapped at one time. DS4DIRF or something like that. DOS could happily use an OS/360 volume but didn't maintain the Formet 3s. We used to switch 2311 volumes between OS and DOS systems - if OS found the DIRF bit (also called the Dirty Bit) on it would recalculate the F3s before starting allocation. It was a useful feature,and we used to ZAP the bit on every now and then as part of housekeeping. In faact I think even OS used to set it on before allocation and clear it afterwards. -- Phil Payne http://www.isham-research.co.uk +44 7833 654 800 -- 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: Legality of z/OS 1.5 in 31-bit mode under z/VM at D/R Test
Edward E. Jaffe wrote: Chase, John wrote: Since one can specify MACHINE=XC and define a 31-bit-only virtual machine, any thoughts on whether it would it be legal (in the US) to IPL z/OS 1.5 (effectively in ARCHLVL=1 mode) on that virtual machine for D/R testing if the real machine is a z/Box? There have been several responses. Amazingly, none of them address the most fundamental issue of all. Your premise is wrong. z/OS does *not* support ESA/XC architecture. It supports only z/Architecture and ESA/390 architecture! If you try to IPL z/OS (any release supporting ESA/390 architecture) in a guest defined with MACHINE XC, you will receive: What is ESA/XC ? -- 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: z/OS 1.7 and Large Sequential Data Set Offering
Phil Payne wrote: Actually, the bit is used by VSE. But it's use was never recorded in any OS mapping of the Format-1 DSCB. The DOS footprint bit? No. You're thinking of a different bit altogether ... in an entirely different control block (Format-4 DSCB)! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Changing Cobol Default Options
I'm merging two lpars and, not surprising, there are some customization differences in COBOL and LE. Most are easily changed and don't really affect how jobs run. However I have two differences that concern me. LPARA (the sending lpar) has INTDATE=ANSI and LPARB (the receiving lpar) has INTDATE=LILIAN. Also LPARA has OPT as the default for TRUNC while LPARB uses STD. I've asked IBM about these but they just quote me sections of the COBOL manuals dealing with the options. They don't say anything about what might happen when I change one value to another. Has anyone ever made these changes? I'm more scared about INTDATE; TRUNC is more easily explained. Thanks Alan Schwartz Assurant Shared Business Services Lead Systems Programmer Phone: 651-361-4758 Fax: 651-361-5625 ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- 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: Legality of z/OS 1.5 in 31-bit mode under z/VM at D/R Test
R.S. wrote: Edward E. Jaffe wrote: There have been several responses. Amazingly, none of them address the most fundamental issue of all. Your premise is wrong. z/OS does *not* support ESA/XC architecture. It supports only z/Architecture and ESA/390 architecture! If you try to IPL z/OS (any release supporting ESA/390 architecture) in a guest defined with MACHINE XC, you will receive: What is ESA/XC ? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HCSA4B10/CCONTENTS -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: Trex Catalog software.
I use TREX on a daily basis to backup my catalogs and maintain my catalog environment...i.e. clean-up errors, etc. I love the product..the support is excellent. As for REORG--TREX can REORG with parameter changes, such as IMBED to NOIMBED, REPLICAT to NOREPLICAT, SPACE allocations, move to a different volume--and can do the REORG while the catalog is open (if preferred) = no system downtime. -- 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
SVC screening and locks
Hi If someone can advice: In the SVC SCREEN table only on pair of lock flag ( CMS or LOCAL) , but different SVC could need different LOCK setting. How can I handle this correctly ? -- 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
Reading a Load Module
I would like to convert a loadlib module to a format that I can read with a REXX Exec. Is this possible? Can VPSPRINT copy a sequential datasets with the FOLD option? Any suggestions would be a great help. Charlie -- 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: Changing Cobol Default Options
I don't have the answer but I know IBM is not going to be much help. It's not a defect, it's a usability issue and the only way IBM is going to help is by sending over somebody from IBM Global Services at $$$/hour. Ah, remember SE's? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Alan Schwartz Sent: Wednesday, March 29, 2006 10:18 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Changing Cobol Default Options I'm merging two lpars and, not surprising, there are some customization differences in COBOL and LE. Most are easily changed and don't really affect how jobs run. However I have two differences that concern me. LPARA (the sending lpar) has INTDATE=ANSI and LPARB (the receiving lpar) has INTDATE=LILIAN. Also LPARA has OPT as the default for TRUNC while LPARB uses STD. I've asked IBM about these but they just quote me sections of the COBOL manuals dealing with the options. They don't say anything about what might happen when I change one value to another. -- 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
No More JES2/JES3 Migration Guides!!!
Please join with me in complaining to IBM that there are no more migration guides for z/OS JES2 and JES3, beginning with z/OS 1.7. These _extremely useful_ books were scrapped because some genius erroneously believed that the z/OS 1.7 Introduction and Release Guide would provide equivalent information. See for yourselves, it doesn't even come close! http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/E0Z2A117/ AFAICT, all of that great JES2/JES3 migration information has been lost! And, at the worst possible time too! (Look how much JES2 exit rewrite is required due to the extensive JES2 infrastructure changes in z/OS 1.7 needed to support large data sets and TCP/IP over NJE! JES3 installations are lucky because no drastic JES3 rewrite was/is needed to support these features. But there will almost certainly come a time for them as well.) The old migration books provided, not just a list of changes and new features, but guidelines and specific details on tolerating/exploiting them. They were an invaluable resource! We need them back! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: Changing Cobol Default Options
And PSR's. Surprisingly the first PSR I ever knew (I was a DOS operator and he was helping us switch from GRASP to POWER) is now part of our DBA group. Alan Charles Mills [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 03/29/2006 01:10 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Changing Cobol Default Options I don't have the answer but I know IBM is not going to be much help. It's not a defect, it's a usability issue and the only way IBM is going to help is by sending over somebody from IBM Global Services at $$$/hour. Ah, remember SE's? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Alan Schwartz Sent: Wednesday, March 29, 2006 10:18 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Changing Cobol Default Options I'm merging two lpars and, not surprising, there are some customization differences in COBOL and LE. Most are easily changed and don't really affect how jobs run. However I have two differences that concern me. LPARA (the sending lpar) has INTDATE=ANSI and LPARB (the receiving lpar) has INTDATE=LILIAN. Also LPARA has OPT as the default for TRUNC while LPARB uses STD. I've asked IBM about these but they just quote me sections of the COBOL manuals dealing with the options. They don't say anything about what might happen when I change one value to another. ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- 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: Reading a Load Module
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of JONES, CHARLIE Sent: Wednesday, March 29, 2006 1:04 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Reading a Load Module I would like to convert a loadlib module to a format that I can read with a REXX Exec. Is this possible? Can VPSPRINT copy a sequential datasets with the FOLD option? Any suggestions would be a great help. Charlie I guess that I'm going to ask: What do you mean by READ?. A load module or program object is readable by REXX as-is. Now, understanding what was read is a different question. What, in particular, are you wanting to accomplish? Look for specific character strings? Look for instruction sequences? -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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: Reading a Load Module
try superzap JONES, CHARLIE [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 03/29/2006 02:03 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Reading a Load Module I would like to convert a loadlib module to a format that I can read with a REXX Exec. Is this possible? Can VPSPRINT copy a sequential datasets with the FOLD option? Any suggestions would be a great help. Charlie -- 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: z/OS 1.7 and Large Sequential Data Set Offering
In faact I think even OS used to set it on before allocation and clear it afterwards. Wasn't it used for the indicator as to whether you had a VTOCIX or not on a pack, in the early 1980's? - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: Reading a Load Module
Depending on what he wants, reading it with Rexx could be a chore, albeit not impossible. Don't forget that key load module data is stored in the directory entry. Much of the directory entry is logically part of the load module. And it's not in the most friendly format for programs without good binary arithmetic and indexing capabilities. (But yes, do-able.) Depending on what he wants to do, formatting it in hex with Superzap (as John suggested) or another utility and parsing the listing with Rexx could be a good option. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Wednesday, March 29, 2006 11:19 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Reading a Load Module -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of JONES, CHARLIE Sent: Wednesday, March 29, 2006 1:04 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Reading a Load Module I would like to convert a loadlib module to a format that I can read with a REXX Exec. Is this possible? Can VPSPRINT copy a sequential datasets with the FOLD option? Any suggestions would be a great help. I guess that I'm going to ask: What do you mean by READ?. A load module or program object is readable by REXX as-is. Now, understanding -- 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: Barbaras (mini-)rant
On Wed, 29 Mar 2006 09:28:45 +1000, Shane Ginnane [EMAIL PROTECTED] wrote: ... Quite a few of us were forked by the merge of the IP stacks in 2.5 ... ... And some of us expressed that feeling a bit more publicly than was called for, perhaps. But the rewrite was needed, and eventually IBM turned it into a really good and reliable product. I'm not convinced they needed to wed it so tightly with Unix System Services, but I bet they are not about to undo that with another rewrite. Pat O'Keefe -- 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: Reading a Load Module
- Original Message - From: McKown, John [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, March 29, 2006 2:19 PM Subject: RE: Reading a Load Module -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of JONES, CHARLIE Sent: Wednesday, March 29, 2006 1:04 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Reading a Load Module I would like to convert a loadlib module to a format that I can read with a REXX Exec. Is this I guess that I'm going to ask: What do you mean by READ?. A load module or program object is readable by REXX as-is. Now, understanding what was read is a different question. What, in particular, are you wanting to accomplish? Look for specific character strings? Look for instruction sequences? John, WTF you be talkin' 'bout Willis? Rexx cannot read a load module as-is. The EXECIO gets an IRX0509E that only RECFM F and V types are supported. Do you have some type of add-on routine that does this? Regards, Tom Conley -- 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: Anyone Using IBM 3592, Sun/STK 9940, or Sun/STK T10000 Cartridges for HSM ML2?
On Mar 28, 2006, at 11:19 PM, Mark van der Eynden wrote: SNIP Just a point of curiosity here... I have been out of touch on this and my knowledge maybe out of date. With the new larger tapes there maybe more than the 255 file limit? When was DFHSM (for that matter TMS) updated to allow for these Longer more dense tapes? Was the field increased to 32760 or did they go for a full word? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- 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: Changing Cobol Default Options
Alan, download the Cobol-Analyser from www.cbttape.org FILE#321. Verify the output after a scan of you load modules. 1. Verfiy the curent compile option INTDATE(ANSI) or INTDATE(LILIAN) 2. Verify if the cobol makes a call to CEECBLDY or CEEDAYS. The Cobol- Analyzer will report such static calls. 3. Intrinsic function was used vs No Intrinsic function was used This might be indicator using function day-of-integer and the other three. Unfortunally you still have to scan the source because it could be another function. Roland -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Alan Schwartz Sent: Wednesday, March 29, 2006 8:18 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Changing Cobol Default Options I'm merging two lpars and, not surprising, there are some customization differences in COBOL and LE. Most are easily changed and don't really affect how jobs run. However I have two differences that concern me. LPARA (the sending lpar) has INTDATE=ANSI and LPARB (the receiving lpar) has INTDATE=LILIAN. Also LPARA has OPT as the default for TRUNC while LPARB uses STD. I've asked IBM about these but they just quote me sections of the COBOL manuals dealing with the options. They don't say anything about what might happen when I change one value to another. Has anyone ever made these changes? I'm more scared about INTDATE; TRUNC is more easily explained. 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
Re: Reading a Load Module
WTF you be talkin' 'bout Willis? Rexx cannot read a load module as-is. The EXECIO gets an IRX0509E that only RECFM F and V types are supported. Do you have some type of add-on routine that does this? Tom, I believe he's referring to the LMGET service which can be issued by REXX to read a load module. Dave Salt SimpList(tm) - The easiest, most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm -- 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
TCP/IP archeology (was Re: Barbaras (mini-)rant
On Tue, 28 Mar 2006 21:20:44 -0500, Shmuel Metz (Seymour J.) shmuel+ibm- [EMAIL PROTECTED] wrote: [Subject changed in response to Ed's bitter complaint. :-) ] ... I suspect the rewrite story is apocryphal. Possibly the details are. But it is a fact that IBM ported a Pascal-based TCP/OP from VM to MVS, including a simulated VMCF. It is also a fact that OS/390 2.5 shipped with a Unix-based TCP/IP. ... Absolutely. I didn't mean to imply otherwise. In fact there are still some Pascal-based parts of TCP/IP as of 1.6. I just doubt the rewrite was done by 2 people over a weekend ... or even that the rewrite was designed by 2 people over one weekend. That was a BIG redesign. (Although that might explain some of the problems in 2.5.) Patrick O'Keefe -- 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: Reading a Load Module
On Wed, 29 Mar 2006 13:03:37 -0600, JONES, CHARLIE [EMAIL PROTECTED] wrote: I would like to convert a loadlib module to a format that I can read with a REXX Exec. Is this possible? You can call most of the Binder APIs directly from Rexx, and they can return all the text (and a great deal more) from a load module. They also work on Program Objects in PDSEs and UNIX files. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Space limit for SMF datasets?
Hi, We are still at OS390 2.10. Our DASD are 3390 model. After converting to a new CICS version (from 1.2 to 2.2), we found out that our SMF datasets were filling up too fast. The reason is that the lenght of standard type 110 monitoring records (that we collect) has hugely increased (we are mostly a CICS shop, with lot of CICS activity). To deal with this problem, we are trying to increase the size of our SMF data sets. However, it seems that the maximum space we can allocate for an SMF dataset is around 5800 cylinders (specifying RECORDSIZE(4086,32767), as shown in the manuals). If we try to allocate more space, we get a catalog overflow error. Questions: Is there a way we can allocate an SMF dataset of 10.000 cylinders? If there is no way to allocate such a dataset, how do you suggest to deal with this problem? Thanks in advance for your help, JUAN MAUTALEN -- 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: No More JES2/JES3 Migration Guides!!!
I did mention this at least a couple times at JES2 SHARE sessions. The good news is that there's a JES2 migration guide on the z/OS 1.7 DVD; the bad news is that it's for JES2 1.5. How useful! By the by, the JES2 1.7 Installation Exits book needs to be read with a salt shaker nearby, e.g. R11 at entry to exit 52 does not really point to the HCT... http://www-03.ibm.com/servers/eserver/zseries/zos/installation/zos17_jes2_migration.html is the only salvation for us JES2 folk. Bob Edward E. Jaffe wrote: Please join with me in complaining to IBM that there are no more migration guides for z/OS JES2 and JES3, beginning with z/OS 1.7. These _extremely useful_ books were scrapped because some genius erroneously believed that the z/OS 1.7 Introduction and Release Guide would provide equivalent information. See for yourselves, it doesn't even come close! http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/E0Z2A117/ AFAICT, all of that great JES2/JES3 migration information has been lost! And, at the worst possible time too! (Look how much JES2 exit rewrite is required due to the extensive JES2 infrastructure changes in z/OS 1.7 needed to support large data sets and TCP/IP over NJE! JES3 installations are lucky because no drastic JES3 rewrite was/is needed to support these features. But there will almost certainly come a time for them as well.) The old migration books provided, not just a list of changes and new features, but guidelines and specific details on tolerating/exploiting them. They were an invaluable resource! We need them back! -- 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: No More JES2/JES3 Migration Guides!!!
On Wed, 29 Mar 2006 11:15:14 -0800, Edward E. Jaffe [EMAIL PROTECTED] wrote: ... and TCP/IP over NJE! ... Ooh! Neat trick! The old migration books provided, not just a list of changes and new features, but guidelines and specific details on tolerating/exploiting them. They were an invaluable resource! We need them back! ... Don't worry. They'll be back ... right after the PLMs. :-( Pat O'Keefe -- 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: Space limit for SMF datasets?
Allocate more MAN data sets (you are not limited to 3 which is the most common configuration I have seen) Speed up your SMF dumps by assigning a preferred SERVICE class to the dump jobs and using DFSMSdfp features like striping the output. We use striped and compressed which makes for a very fast read back of a days data at the end of the day. Tailor your 110 records using the CICS MCT. Patrick Mullen sent me this minimalist MCT they used. His original post included this which got me interested in the MCT. We are still debating what to cut and in and out but this seems to have worked wonders for others. I don't think anyone has mentioned it yet, so I will. You can use an MCT in CICS with appropriate EXCLUDE and INCLUDE statements to reduce the amount of data it produces by a huge factor. After carefully checking which fields were required by our accounting system, I coded an MCT which reduced the amount of data produced per transaction from 1200+ bytes (generated by the default MCT in CICS TS 1.3) to just 52 bytes. Type 110 records dropped from 38% of the byte count of our SMF dataset to 2%. *-- * Field Name Size Nickname Description * *8 DFHTASK S0088 USRCPUT User task cpu time * 71 DFHPROG C0718 PGMNAME Program name *-- * DFHMCT TYPE=INITIAL,SUFFIX=ZZ * DFHMCT TYPE=RECORD,CLASS=PERFORM, X EXCLUDE=ALL,X INCLUDE=(8,71) * DFHMCT TYPE=FINAL END Good Luck! Best Regards, Sam Knutson, GEICO 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 Mautalen Juan Guillermo Sent: Wednesday, March 29, 2006 3:27 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Space limit for SMF datasets? Hi, We are still at OS390 2.10. Our DASD are 3390 model. After converting to a new CICS version (from 1.2 to 2.2), we found out that our SMF datasets were filling up too fast. The reason is that the lenght of standard type 110 monitoring records (that we collect) has hugely increased (we are mostly a CICS shop, with lot of CICS activity). To deal with this problem, we are trying to increase the size of our SMF data sets. However, it seems that the maximum space we can allocate for an SMF dataset is around 5800 cylinders (specifying RECORDSIZE(4086,32767), as shown in the manuals). If we try to allocate more space, we get a catalog overflow error. Questions: Is there a way we can allocate an SMF dataset of 10.000 cylinders? If there is no way to allocate such a dataset, how do you suggest to deal with this problem? Thanks in advance for your help, JUAN MAUTALEN 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
Re: Space limit for SMF datasets?
As well as allocating larger SMF data sets, why not allocate more? This should give your dump process enough time to dump and clear any filled data set before it is needed again. Don Imbriale -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mautalen Juan Guillermo Sent: Wednesday, March 29, 2006 3:27 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Space limit for SMF datasets? Hi, We are still at OS390 2.10. Our DASD are 3390 model. After converting to a new CICS version (from 1.2 to 2.2), we found out that our SMF datasets were filling up too fast. The reason is that the lenght of standard type 110 monitoring records (that we collect) has hugely increased (we are mostly a CICS shop, with lot of CICS activity). To deal with this problem, we are trying to increase the size of our SMF data sets. However, it seems that the maximum space we can allocate for an SMF dataset is around 5800 cylinders (specifying RECORDSIZE(4086,32767), as shown in the manuals). If we try to allocate more space, we get a catalog overflow error. Questions: Is there a way we can allocate an SMF dataset of 10.000 cylinders? If there is no way to allocate such a dataset, how do you suggest to deal with this problem? Thanks in advance for your help, JUAN MAUTALEN *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** -- 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: Systems Programmer Levels Justification
I hear you Dave. We just hired an App Pgmr from within our dept. We tried for so long to find a SysProg and could find one. So we had to hire from within and train that person. We are still unable to fill our other SysProg position here in San Antonio.. Thanks everyone for their help on Systems Programmer Levels Justification. Desi de la Garza Systems Programmer Bexar County Information Services [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Low, David Sent: Wednesday, March 29, 2006 11:46 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Systems Programmer Levels Justification At the same time provide management with information as to why SysProgs are higher salaried than application programmers. They are at a loss as to why that is. Weird that they do not question why a network tech makes more than the applications also. I think many sysprogs are also application programmers, or started out in that position. I spent 9 months as a code warrior before switching to systems. I've coded quite a few assembler, cobol and cics apps in my position as a sysprog. Also, I sometimes debug applications when a programmer needs such assistance, ie stg violations. App programmers here don't have the knowledge to read dumps and xpediter doesn't always catch them. Dave Low -- 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: No More JES2/JES3 Migration Guides!!!
Ed, Have you checked the z/os 1.7 migration guides? I believe that it was IBM's intention to consolidate ALL the migration information into a single document. Lynette -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward E. Jaffe Sent: Wednesday, March 29, 2006 1:15 PM To: IBM-MAIN@BAMA.UA.EDU Subject: No More JES2/JES3 Migration Guides!!! Please join with me in complaining to IBM that there are no more migration guides for z/OS JES2 and JES3, beginning with z/OS 1.7. These _extremely useful_ books were scrapped because some genius erroneously believed that the z/OS 1.7 Introduction and Release Guide would provide equivalent information. See for yourselves, it doesn't even come close! http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/E0Z2A117/ AFAICT, all of that great JES2/JES3 migration information has been lost! And, at the worst possible time too! (Look how much JES2 exit rewrite is required due to the extensive JES2 infrastructure changes in z/OS 1.7 needed to support large data sets and TCP/IP over NJE! JES3 installations are lucky because no drastic JES3 rewrite was/is needed to support these features. But there will almost certainly come a time for them as well.) The old migration books provided, not just a list of changes and new features, but guidelines and specific details on tolerating/exploiting them. They were an invaluable resource! We need them back! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: No More JES2/JES3 Migration Guides!!!
Tom Wasik from JES2 development was at SHARE in Seattle the whole week. In once case where we cited missing doc for exit conversion, Tom logged on via wireless during the session and made some manual updates on the spot. Complaints about doc do get attention. . . JO.Skip Robinson Southern California Edison Company SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Bob Rutledge [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 03/29/2006 12:38 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: No More JES2/JES3 Migration Guides!!! I did mention this at least a couple times at JES2 SHARE sessions. The good news is that there's a JES2 migration guide on the z/OS 1.7 DVD; the bad news is that it's for JES2 1.5. How useful! By the by, the JES2 1.7 Installation Exits book needs to be read with a salt shaker nearby, e.g. R11 at entry to exit 52 does not really point to the HCT... http://www-03.ibm.com/servers/eserver/zseries/zos/installation/zos17_jes2_migration.html is the only salvation for us JES2 folk. -- 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: Reading a Load Module
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Conley Sent: Wednesday, March 29, 2006 2:11 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Reading a Load Module snip John, elided you be talkin' 'bout Willis? Rexx cannot read a load module as-is. The EXECIO gets an IRX0509E that only RECFM F and V types are supported. Do you have some type of add-on routine that does this? Regards, Tom Conley Add LRECL=1,RECFM=FB to the DD statement and you can read it. One character at a time. OK, probably not what was wanted. But it does work. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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: Space limit for SMF datasets?
On Wed, 29 Mar 2006 17:27:09 -0300, Mautalen Juan Guillermo [EMAIL PROTECTED] wrote: snip Questions: Is there a way we can allocate an SMF dataset of 10.000 cylinders? If there is no way to allocate such a dataset, how do you suggest to deal with this problem? SMF dsns still can't be bigger than 4G (VSAM limit). Size isn't the issue, it's being able to dump them quicker than they fill up. Are you dumping to disk or tape? What are you using for CISIZE and BUFFERSPACE? Are you using BUNFD in your dump job? I used this at a shop that was having similar problem: BUFFERSPACE(106496) - CONTROLINTERVALSIZE(26624) - RECORDSIZE(26614 32767) - Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] Systems Programming expert at http://expertanswercenter.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: I/O Retries
In a message dated 3/28/2006 2:52:42 P.M. Central Standard Time, [EMAIL PROTECTED] writes: In a multiple CPU environment, z/OS normally only has a single engine enabled for I/O interrupts. I think this is because the IOS supervisor does a TPI instruction which will test for pending interrupts. If the interrupts were enabled on a second engine, it would have fielded the interrupt which was pended. The use of TPI increases the effiency of the I/O processing due to decrease I/O interrupts and their overhead. A multi-processing z/OS starts out with one CPU enabled for I/O interrupts. As interrupts occur, IOS accumulates a count of all interrupts processing by switching PSWs When IOS is about to redispatch the interrupted work, it tests for one or more interrupts pending in the channel subsystem by executing the TPI instruction. If an interrupt is processed because of the TPI, IOS adds one to the TPI-fielded bucket instead of the processor-interrupted buciet. TPI allows IOS to continue processing I/O interrupts without having to restore the interrupted work's status, enable, and then immediately switch PSWs again, save status, and start processing the interrupt that was pending. This is more efficient than always reenabling and redispatching. SRM periodically computes the TPI-fielded % of interrupts from the two buckets mentioned above and checks that against CPENABLE percentages to decide if it is time to pick another CPU and change its system mask to where it can also be interrupted with I/O interrupts. This will reduce the I/O interrupt elongation factor, but at the cost of slowing down the work that is on the CPU newly enabled for interrupts. Whenever an interrupt occurs, there is a context switch between the working set of TLB entries and high-speed instruction cache of the interrupted work and that of the new context - IOS. This means that the CPU slows down a little every time an interrupt occurs, when interrupted work is redispatched, or whenever the dispatcher first dispatches a different work unit for any reason. Bill Fairchild -- 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: Anyone Using IBM 3592, Sun/STK 9940, or Sun/STK T10000 Cartridges for HSM ML2?
Just a point of curiosity here... I have been out of touch on this and my knowledge maybe out of date. With the new larger tapes there maybe more than the 255 file limit? When was DFHSM (for that matter TMS) updated to allow for these Longer more dense tapes? I don't believe that the file number was ever limited to 255. The field in the HDR1 label is 4 digits, from 0001 to , and I believe it has always been that way. The field containing the number of blocks in a file was increased, from 6 digits to 10, some years ago -- Bruce Black Senior Software Developer Innovation Data Processing -- 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.7 and Large Sequential Data Set Offering
In a message dated 3/29/2006 12:07:09 P.M. Central Standard Time, [EMAIL PROTECTED] writes: The DOS footprint bit? It _was_ mapped at one time. DS4DIRF or something like that. DOS could happily use an OS/360 volume but didn't maintain the Formet 3s. We used to switch 2311volumes between OS and DOS systems - if OS found the DIRF bit (also called the Dirty Bit) on it would recalculate the F3s before starting allocation. It was a useful feature,and we used to ZAP the bit on every now and then as part of housekeeping. In faact I think even OS used to set it on before allocation and clear it afterwards. Correct. The acronym stands for DASDM Interrupt Recording Facility. The bit is (or was) turned on at the beginning of a long process in which multiple DSCBs had to be updated. When all updates were done, the bit was turned off. If on a new allocate the bit was found to be on, then DADSM knew that the free DSCB chain was not necessarily correct, so DASDM would automatically rebuild the format 3 DSCB chain. It was called the dirty bit because (a) DIRF sounds a lot like dirt and (b) the F3 DSCB chain was possibly dirty/contaminated/non-kosher/hosed if the bit was on. When you wanted to force a cleanup, you would IMASPZAP the bit on, then allocate something - anything - like a one-track data set with DISP=(NEW,DELETE) just to force DASDM to rebuild the F3 chain. Bill Fairchild -- 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
Fw: Changing Cobol Default Options
I don't know what you wanted to hear from IBM. However, if your question is whether differences between these options will change run-time behavior, the answer is DEFINITELY yes. 1) TRUNC - is a compile-time option. Do you do compiles on both LPARs? If not, a change won't impact anything. If so, then: TRUNC(OPT) is DEFINITELY a better performance option. TRUHNC(STD) *will* change the behavior of applications that have binary (USAGE COMP, COMP-4, or BINARY - not COMP-5) where the individual fields can have values larger than the PICTURE specifies. (e.g. 32000 in PIC COMP) field. 2) INTDATE is a run-time option that ONLY impacts CALLs to LE date features. (Such calls can be explicit or implicit by use of COBOL date intrinsic functions). If you use LE callable services in non-COBOL (e.g. PL/I or Assembler) applications, then you PROBABLY want to use LILLIAN. If you are a COBOL-only shop, then using ANSI will give you portable results that conform to the ANSI Standard. *** Is this the type of information you are looking for? This really IS all described (in more detail) in the IBM documentation. [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] ... I'm merging two lpars and, not surprising, there are some customization differences in COBOL and LE. Most are easily changed and don't really affect how jobs run. However I have two differences that concern me. LPARA (the sending lpar) has INTDATE=ANSI and LPARB (the receiving lpar) has INTDATE=LILIAN. Also LPARA has OPT as the default for TRUNC while LPARB uses STD. I've asked IBM about these but they just quote me sections of the COBOL manuals dealing with the options. They don't say anything about what might happen when I change one value to another. Has anyone ever made these changes? I'm more scared about INTDATE; TRUNC is more easily explained. 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
Re: Anyone Using IBM 3592, Sun/STK 9940, or Sun/STK T10000 Cartridges for HSM ML2?
Ed Gould wrote: Just a point of curiosity here... I have been out of touch on this and my knowledge maybe out of date. With the new larger tapes there maybe more than the 255 file limit? When was DFHSM (for that matter TMS) updated to allow for these Longer more dense tapes? Was the field increased to 32760 or did they go for a full word? snip z/OS R7: Extend Tape Table of Contents (TTOC) records to raise the DFSMShsm limit on the number of data sets per tape to support more than 330,000 data sets per volume. This can provide better DFSMShsm exploitation of new larger capacity tape cartridges by allowing over 1,000,000 data sets per migration or backup tape volume. ( Note: Other factors also affect the number of data sets that can be stored on a tape.) (BTW, 255? How long ago was the limit 255?) -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Reading a Load Module
And if it's a program object, all bets are off - time for the (at least) $15K DFSMSdfp Advanced Customization Guide, or parse SPZAP output. Later, Ray -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Wednesday March 29 2006 12:02 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Reading a Load Module Depending on what he wants, reading it with Rexx could be a chore, albeit not impossible. Don't forget that key load module data is stored in the directory entry. Much of the directory entry is logically part of the load module. And it's not in the most friendly format for programs without good binary arithmetic and indexing capabilities. (But yes, do-able.) Depending on what he wants to do, formatting it in hex with Superzap (as John suggested) or another utility and parsing the listing with Rexx could be a good option. -- 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 Change Management / Change Control Procedures
Procedures and disciplines only. I'm not too fussed about the programs and code at this point. This is more research for a comparison of application change management versus operating system change management. Plenty of data out there for the application side, but almost nothing has been written on the OS side. Thanks. On Wed, 29 Mar 2006 11:12:37 -0500, Froberg, David C [EMAIL PROTECTED] wrote: Doc, Are you looking for programs and code or discipline and procedures? I'm not sure if this helps, but The Visible OPS Handbook (http://www.tripwire.com/practices/visops.cfm) by Kevin Behr, Gene Kim and George Spafford lays out a superb framework for change and configuration management. Is that the sort of information you're looking for? Dave Froberg I'm trying to look up some sample change management / change control procedures for operating system and system/subsystem utility changes, but I'm not having much luck in a Google search (or a search of IBM-MAIN, for that matter). I'm pretty sure they'd have to be more rigorous than application CCPs, if only for the wide-ranging impact those changes can have. Does anyone out there have some sites/samples/examples of workable operating system CCPs? If so, I'd appreciate a copy or a link. Many thanks. Doc Farmer -- 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: SVC screening and locks
On Wed, 29 Mar 2006 20:56:42 +0200 Miklos Szigetvari [EMAIL PROTECTED] wrote: :Hi : :If someone can advice: :In the SVC SCREEN table only on pair of lock flag ( CMS or LOCAL) :, but different SVC could need different LOCK setting. :How can I handle this correctly ? Get them yourself, later. You have to provide the function of the SVC dispatcher anyway. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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.7 and Large Sequential Data Set Offering
(IBM Mainframe Discussion List) wrote: ... The acronym stands for DASDM Interrupt Recording Facility. The bit is (or was) turned on at the beginning of a long process in which multiple DSCBs had to be updated. When all updates were done, the bit was turned off. If on a new allocate the bit was found to be on, then DADSM knew that the free DSCB chain was not necessarily correct, so DASDM would automatically rebuild the format 3 DSCB chain. It was called the dirty bit because (a) DIRF sounds a lot like dirt and (b) the F3 DSCB chain was possibly dirty/contaminated/non-kosher/hosed if the bit was on. Talk about a digression. Phil is talking about the WRONG bit altogether! The VSE bit that wasn't mapped was x'20' in DS1FLAG1 -- not x'04' in DS4VTOCI. Sheesh! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: TCP/IP (was: Barbaras (mini-)rant)
I'm not convinced they needed to wed it so tightly with Unix System Services, but I bet they are not about to undo that with another rewrite. I think they had no real choice. The original spec was written for UNIX, so they wrote it to call UNIX system functions. - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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: Barbaras (mini-)rant
Dave Cartwright wrote: I'm with Jim on this. I was a contractor in the mid to late '90's and came across the early TCPIP stack, written in PASCAL and ported from VM. As I recall it performed OK, and had some quite advanced features like VIPA which was the subject of another recent thread. The Cisco man at the scottish bank I worked was quite impressed. the base pascal/vs implementation on vm used approx. 3090 processor getting 44kbytes/sec thruput. i added rfc 1044 support to the base ... and in some tuning at cray research was getting sustained 1mbyte/sec between a 4341-clone and a cray ... using only modest amount of the 4341-clone cpu (around 25 times the data rate for a small fraction of cpu). misc. past posts mentioning adding rfc 1044 support to http://www.garlic.com/~lynn/subnetwork.html#1044 slight drift ... my rfc index http://www.garlic.com/~lynn/rfcietff.htm other posts on high-speed data transport project http://www.garlic.com/~lynn/subnetwork.html#hsdt we were operating a high-speed backbone ... but were not allowed to actually bid on nsfnet1 (original internet backbone) ... however, we did get an technical audit by NSF that said what we had running was at least five years ahead of all nsfnet1 bid submissions. i was asked to be the red team for nsfnet2 bid ... there were something like 20 people from seven labs around the world that were the blue team (although only the blue team proposal was actually allowed to be submitted). minor past refs: http://www.garlic.com/~lynn/99.html#37a Internet and/or ARPANET? http://www.garlic.com/~lynn/2000d.html#77 Is Al Gore The Father of the Internet? http://www.garlic.com/~lynn/2003c.html#46 diffence between itanium and alpha http://www.garlic.com/~lynn/2004g.html#12 network history http://www.garlic.com/~lynn/2004l.html#1 Xah Lee's Unixism http://www.garlic.com/~lynn/2005d.html#13 Cerf and Kahn receive Turing award http://www.garlic.com/~lynn/2005u.html#53 OSI model and an interview http://www.garlic.com/~lynn/2006e.html#38 The Pankian Metaphor part of old reference from 1988 (although not of the added rfc 1044 support) TITLE IBM TCP/IP FOR VM (TM) RELEASE 1 MODIFICATION LEVEL 2 WITH ADDITIONAL FUNCTION AND NEW NETWORK FILE SYSTEM FEATURE ABSTRACT IBM announces Transmission Control Protocol/Internet Protocol (TCP/IP) for VM (5798-FAL) Release 1 Modification Level 2. Release 1.2 contains functional enhancements and a new optional Network File System (NFS) (1) feature. VM systems with the NFS feature installed may act as a file server for AIX (TM) 2.2, UNIX (2) and other systems with the NFS 3.2 client function installed. Additional functional enhancements in Release 1.2 include: support for 9370 X.25 Communications Subsystem, X Window System (3) client function, the ability to use an SNA network to link two TCP/IP networks, and a remote execution daemon (server). -- 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: Space limit for SMF datasets?
Questions: Is there a way we can allocate an SMF dataset of 10.000 cylinders? If there is no way to allocate such a dataset, how do you suggest to deal with this problem? Standard VSAM has a limit of 2GB. With an extended format file you can go to 4GB times the CI-size (4K in SMF's case). Or, you can allocate more of them at 2GB. Or, dump more frequently. - -teD I’m an enthusiastic proselytiser of the universal panacea I believe in! -- 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 Change Management / Change Control Procedures
Doc Search on ITIL ITSM change management itSMF and you'll be swamped. http://www.itsmfusa.org would be a place for you to start You could buy the ITIL Service Support manual from itSMF-US for $US100 or so, and use the 50-60 pages on Chg Mgt as a start for operational change mgt procedures and basic best practice guidelines (Release Mgt covers software release whether OS, apps, sys sw, etc) Procedures are not oriented to a particular platform. Have been adopted by at least one US-based global TLA outsourcer for their chg mgt procedures as an example. Process defginiton and procedures grew out of IBM's Information Systems Mgt Architecture from the late 1970's/early 80's. Were adapted to UK whole of govt in the 80's and now extended around the world. Wealth of material covering procedure, guidelines, watchouts, process flowcharts, attributes, benefits, problems, how to implement, relationships between ITSM disciplines (Service desk/incident mgt, problem mgt, change mgt, config mgt, release mgt, capacity, DR, SLM, availability, financial, security). Standard is BS15000 in UK and AS8018 in Oz, and heading towards ISO. regards, peter Mainframe Capacity mangler and ITSM consultant Victorian Workcover Authority Melb, Australia Doc Farmer [EMAIL PROTECTED] HOO.CO.UK To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU z/OS Change Management / Change Control Procedures 29/03/2006 05:39 PM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU Greetings! I'm trying to look up some sample change management / change control procedures for operating system and system/subsystem utility changes, but I'm not having much luck in a Google search (or a search of IBM-MAIN, for that matter). I'm pretty sure they'd have to be more rigorous than application CCPs, if only for the wide-ranging impact those changes can have. Does anyone out there have some sites/samples/examples of workable operating system CCPs? If so, I'd appreciate a copy or a link. Many thanks. Doc Farmer IMPORTANT - (1) The contents of this email and its attachments may be confidential and privileged. Any unauthorised use of the contents is expressly prohibited. If you receive this email in error, please contact us, and then delete the email. (2) Before opening or using attachments, check them for viruses and defects. The contents of this email and its attachments may become scrambled, truncated or altered in transmission. Please notify us of any anomalies. (3) Our liability is limited to resupplying the email and attached files or the cost of having them resupplied. (4) We collect personal information to enable us to perform our functions. For more information about the use, access and disclosure of this information, refer to our privacy policy at our website. -- 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
Large SMF Data Set Allocation
Juan, To allocate a 10,000 cylinder data set for SMF use, the data set has to be SMS managed and you will need to use DATACLASS and STORAGECLASS parameters in your DEFINE CLUSTER control cards for IDCAMS. The DATACLASS you use must specify the extended format option as either preferred and/or required. The largest data set you can allocate without using the extended format options is around 4300 cylinders. These control statements actually worked - DEFINE CLUSTER( - DATACLASS(MOD54) - STORAGECLASS(SMSML0) - BUFFERSPACE(1677604) - CONTROLINTERVALSIZE(26624) - CYLINDERS(7000) - NAME(NOAL.MANX.TEST) - NONINDEXED - RECORDSIZE(4086,32767) - REUSE - VOLUME(T04000) - SHAREOPTIONS(2) - SPANNED - SPEED - ) - DATA( - NAME(NOAL.MANX.TEST.DATA) ) HITACHI DATA SYSTEMS Raymond E. Noal Lab Manager, San Diego Facility Office: (858) 537 - 3268 Cell: (858) 248 - 1172 -- 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: Changing Cobol Default Options
I know that TRUNC(OPT) is preferred. But the lpar that uses OPT is moving into the lpar that has STD as the default. When a program is recompiled will it function the same albeit less efficient? My feeling is it will I appreciate your explanation of INTDATE only impacting calls to LE date services. We don't have a PL1 compiler but they do use Assembler and Easytrieve and do a fair amount of inter-language linking of routines. I don't know how difficult it will be to make the kind of determination needed especially looking at the implicit functions probably in use. I've had in reserve the plan to have our Endevor processes pass the sending lpars parms to their compiles but that won't help compiles done outside of Endevor. More analysis to come. Alan Schwartz Assurant Shared Business Services Lead Systems Programmer Phone: 651-361-4758 Fax: 651-361-5625 Bill Klein [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 03/29/2006 03:46 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Fw: Changing Cobol Default Options I don't know what you wanted to hear from IBM. However, if your question is whether differences between these options will change run-time behavior, the answer is DEFINITELY yes. 1) TRUNC - is a compile-time option. Do you do compiles on both LPARs? If not, a change won't impact anything. If so, then: TRUNC(OPT) is DEFINITELY a better performance option. TRUHNC(STD) *will* change the behavior of applications that have binary (USAGE COMP, COMP-4, or BINARY - not COMP-5) where the individual fields can have values larger than the PICTURE specifies. (e.g. 32000 in PIC COMP) field. 2) INTDATE is a run-time option that ONLY impacts CALLs to LE date features. (Such calls can be explicit or implicit by use of COBOL date intrinsic functions). If you use LE callable services in non-COBOL (e.g. PL/I or Assembler) applications, then you PROBABLY want to use LILLIAN. If you are a COBOL-only shop, then using ANSI will give you portable results that conform to the ANSI Standard. ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- 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
Changing Cobol Default Options
I made TWO errors talking about INTDATE It is a compile-time, not a run-time, option. (So again, if you don't compile on both LPARs, then it won't impact you). Also, it impacts only COBOL intrinsic functions - not LE callable services (but setting it to LILLIAN will make the intrinsic functions give the same answers as the callable services. Sorry about the errors. -Original Message- I don't know what you wanted to hear from IBM. However, if your question is whether differences between these options will change run-time behavior, the answer is DEFINITELY yes. 1) TRUNC - is a compile-time option. Do you do compiles on both LPARs? If not, a change won't impact anything. If so, then: TRUNC(OPT) is DEFINITELY a better performance option. TRUHNC(STD) *will* change the behavior of applications that have binary (USAGE COMP, COMP-4, or BINARY - not COMP-5) where the individual fields can have values larger than the PICTURE specifies. (e.g. 32000 in PIC COMP) field. 2) INTDATE is a run-time option that ONLY impacts CALLs to LE date features. (Such calls can be explicit or implicit by use of COBOL date intrinsic functions). If you use LE callable services in non-COBOL (e.g. PL/I or Assembler) applications, then you PROBABLY want to use LILLIAN. If you are a COBOL-only shop, then using ANSI will give you portable results that conform to the ANSI Standard. *** Is this the type of information you are looking for? This really IS all described (in more detail) in the IBM documentation. [EMAIL PROTECTED] wrote in message news:OF2F330E87.D953EB36-ON85257140.00629F35-86257140.006482F [EMAIL PROTECTED]... I'm merging two lpars and, not surprising, there are some customization differences in COBOL and LE. Most are easily changed and don't really affect how jobs run. However I have two differences that concern me. LPARA (the sending lpar) has INTDATE=ANSI and LPARB (the receiving lpar) has INTDATE=LILIAN. Also LPARA has OPT as the default for TRUNC while LPARB uses STD. I've asked IBM about these but they just quote me sections of the COBOL manuals dealing with the options. They don't say anything about what might happen when I change one value to another. Has anyone ever made these changes? I'm more scared about INTDATE; TRUNC is more easily explained. 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
Re: Large SMF Data Set Allocation
On Wed, 29 Mar 2006 14:13:07 -0800, Raymond Noal [EMAIL PROTECTED] wrote: Juan, To allocate a 10,000 cylinder data set for SMF use, the data set has to be SMS managed and you will need to use DATACLASS and STORAGECLASS parameters in your DEFINE CLUSTER control cards for IDCAMS. The DATACLASS you use must specify the extended format option as either preferred and/or required. The largest data set you can allocate without using the extended format options is around 4300 cylinders. Unless something has changed that isn't documented, extended format is not an option for SMF. Note: SMF does not support extended-addressability VSAM data sets. Thus, the largest SMF data set cannot be larger than 4 gigabytes. For example, you must limit the number of cylinders you request to a maximum of 5800 for a data set on a 3390 device type. (from z/OS 1.7 SMF manual) http://tinyurl.com/faxn4 Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] Systems Programming expert at http://expertanswercenter.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: Fw: Changing Cobol Default Options
Alan Schwartz wrote: I know that TRUNC(OPT) is preferred. But the lpar that uses OPT is moving into the lpar that has STD as the default. When a program is recompiled will it function the same albeit less efficient? My feeling is it will Not likely. TRUNC(STD) says truncate to the picture. So if you have PIC S99 BINARY when you move a constant or a data item with a value of 200, the defined item will end up with a value of 00 (only 2 9s in the picture, so truncate to two decimal digits to the left of the decimal point). Not likely what you want. I appreciate your explanation of INTDATE only impacting calls to LE date services. We don't have a PL1 compiler but they do use Assembler and Easytrieve and do a fair amount of inter-language linking of routines. I don't know how difficult it will be to make the kind of determination needed especially looking at the implicit functions probably in use. I've had in reserve the plan to have our Endevor processes pass the sending lpars parms to their compiles but that won't help compiles done outside of Endevor. More analysis to come. Kind regards, -Steve Comstock -- 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: Changing Cobol Default Options
It is not out of the question - but it does violate the SMPE approach - to have two sets of COBOL customization on one machine. Basically, you assemble and link one set of compiler options into LOADLIBA and the other set into LOADLIBB. Then programmers who formerly used LPAR A use //STEPLIB DD DSN=LOADLIBA,DISP=SHR //DD the real compiler load library And programmers who formerly used LPAR B use //STEPLIB DD DSN=LOADLIBB,DISP=SHR //DD the real compiler load library Various other combinations involving LPA and/or only two load libraries are obviously possible. Just make sure everybody finds the right options load module FIRST. I know for a fact that this works. At Syspoint we are using this approach to support multiple customers with different customization requirements on a single compile server. Yes, I know it won't be painless for you - involves proc changes, etc. For that matter, you can just have two complete installs of COBOL and customize them separately. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Alan Schwartz Sent: Wednesday, March 29, 2006 10:18 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Changing Cobol Default Options I'm merging two lpars and, not surprising, there are some customization differences in COBOL and LE. Most are easily changed and don't really affect how jobs run. However I have two differences that concern me. LPARA (the sending lpar) has INTDATE=ANSI and LPARB (the receiving lpar) has INTDATE=LILIAN. Also LPARA has OPT as the default for TRUNC while LPARB uses STD. I've asked IBM about these but they just quote me -- 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: Systems Programmer Levels Justification
This might be a worthwhile visit: http://www.bls.gov/oco/home.htm. Specifically: http://www.bls.gov/oco/ocos110.htm. Regards, Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Desi de la Garza Sent: Tuesday, March 28, 2006 12:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Systems Programmer Levels Justification MVS Listers, We are in the process of justifying the requirement of having multiple levels of SysProg job titles depending on experience and knowledge. At the same time provide management with information as to why SysProgs are higher salaried than application programmers. They are at a loss as to why that is. Weird that they do not question why a network tech makes more than the applications also. Can someone guide me to where I may be able to locate such info? Thanks, Desi de la Garza Systems Programmer Bexar County Information Services [EMAIL PROTECTED] -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- 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.7 and Large Sequential Data Set Offering
On Wed, 29 Mar 2006 13:58:00 -0800, Edward E. Jaffe [EMAIL PROTECTED] wrote: ... Talk about a digression. Phil is talking about the WRONG bit altogether! The VSE bit that wasn't mapped was x'20' in DS1FLAG1 -- not x'04' in DS4VTOCI. Sheesh! ... Well, ok, but it was a BIT. He got that part right. They're hard to tell apart, especially when they're not mapped. Pat O'Keefe -- 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: Bringing the fun back to z/OS - new course
there is also the folklore of the contractor hired to do the original tcp/ip implementation in vtam. the initial try had tcp benchmark w/thruput much higher than lu6.2. it was explained to him that everybody KNEW that a CORRECT tcp/ip implementation would have thruput much lower than lu6.2 ... and they were only willing to accept a CORRECT protocol implementation. the contract was handled by a group that was sometimes called cpd-west located in palo alto sq (corner of el camino and page mill). -- 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: Systems Programmer Levels Justification
Thanks to everyone. Now if we only could find a SysProg... Desi de la Garza Systems Programmer Bexar County Information Services [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Neubert, Kevin (DIS) Sent: Wednesday, March 29, 2006 6:10 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Systems Programmer Levels Justification This might be a worthwhile visit: http://www.bls.gov/oco/home.htm. Specifically: http://www.bls.gov/oco/ocos110.htm. Regards, Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Desi de la Garza Sent: Tuesday, March 28, 2006 12:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Systems Programmer Levels Justification MVS Listers, We are in the process of justifying the requirement of having multiple levels of SysProg job titles depending on experience and knowledge. At the same time provide management with information as to why SysProgs are higher salaried than application programmers. They are at a loss as to why that is. Weird that they do not question why a network tech makes more than the applications also. Can someone guide me to where I may be able to locate such info? Thanks, Desi de la Garza Systems Programmer Bexar County Information Services [EMAIL PROTECTED] -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- 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: Anyone Using IBM 3592, Sun/STK 9940, or Sun/STK T10000 Cartridges for HSM ML2?
Ed, As others have stated, the file-limit was never 255. It used to be (as Bruce indicated) and still is if you use JCL. However, if you do OPEN TYPE=J and modify the JFCB file-sequence you can go up to 32k or 64k (I can't remember if its a 2-byte un-signed or a half-word). But the number of physical files is now much larger then . Of course, if you want to read one of these files you will not be able to use JCL (which does kind of defeat the purpose); but for stacking-applications it might be useful. To my knowledge the only 255 limit left is the number of volumes a single file can be cataloged across. Though of course with today's capacity, 255-volumes is a LOT of data. Even if it was 255 small virtual-volumes; that's a lot of volumes for a single dataset. Still, this limitation does seem old. This might be a JFCB limitation as well, not sure if the volume-count can go beyond 255 for a single file. Russell Witt CA-1 Level-2 Support Manager -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Ed Gould Sent: Wednesday, March 29, 2006 2:18 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Anyone Using IBM 3592, Sun/STK 9940, or Sun/STK T1 Cartridges for HSM ML2? On Mar 28, 2006, at 11:19 PM, Mark van der Eynden wrote: SNIP Just a point of curiosity here... I have been out of touch on this and my knowledge maybe out of date. With the new larger tapes there maybe more than the 255 file limit? When was DFHSM (for that matter TMS) updated to allow for these Longer more dense tapes? Was the field increased to 32760 or did they go for a full word? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: No More JES2/JES3 Migration Guides!!!
On Mar 29, 2006, at 1:15 PM, Edward E. Jaffe wrote: Please join with me in complaining to IBM that there are no more migration guides for z/OS JES2 and JES3, beginning with z/OS 1.7. These _extremely useful_ books were scrapped because some genius erroneously believed that the z/OS 1.7 Introduction and Release Guide would provide equivalent information. See for yourselves, it doesn't even come close! http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/E0Z2A117/ AFAICT, all of that great JES2/JES3 migration information has been lost! And, at the worst possible time too! (Look how much JES2 exit rewrite is required due to the extensive JES2 infrastructure changes in z/OS 1.7 needed to support large data sets and TCP/IP over NJE! JES3 installations are lucky because no drastic JES3 rewrite was/is needed to support these features. But there will almost certainly come a time for them as well.) The old migration books provided, not just a list of changes and new features, but guidelines and specific details on tolerating/ exploiting them. They were an invaluable resource! We need them back! Ed, Talk to your friendly SE:-) Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Anyone Using IBM 3592, Sun/STK 9940, or Sun/STK T10000 Cartridges for HSM ML2?
On Mar 29, 2006, at 3:33 PM, Bruce Black wrote: Just a point of curiosity here... I have been out of touch on this and my knowledge maybe out of date. With the new larger tapes there maybe more than the 255 file limit? When was DFHSM (for that matter TMS) updated to allow for these Longer more dense tapes? I don't believe that the file number was ever limited to 255. The field in the HDR1 label is 4 digits, from 0001 to , and I believe it has always been that way. The field containing the number of blocks in a file was increased, from 6 digits to 10, some years ago Bruce, I remember trying to create a volume that had more than 255 files on it. I ran into issues. This was approximately 10 years ago. I remember vaguely looking through HSM's CDS's a while ago and seeing a field that was 1 byte that indicated the relative file on the tape. Again this was a while ago (before the huge capacity drive became available). I thought that HSM used that field to skip to the file where the migrated was on the real of tape. Both of the above are remembrances so I could be incorrect. I do remember coming up with a message (from the converter) that 255 was the max, IIRC. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Anyone Using IBM 3592, Sun/STK 9940, or Sun/STK T10000 Cartridges for HSM ML2?
On Mar 29, 2006, at 3:46 PM, John Eells wrote: z/OS R7: Extend Tape Table of Contents (TTOC) records to raise the DFSMShsm limit on the number of data sets per tape to support more than 330,000 data sets per volume. This can provide better DFSMShsm exploitation of new larger capacity tape cartridges by allowing over 1,000,000 data sets per migration or backup tape volume. ( Note: Other factors also affect the number of data sets that can be stored on a tape.) (BTW, 255? How long ago was the limit 255?) John, Thanks. I remember crawling one time through HSM CDS's and I thought that they had a 1 byte field (255) . This was quite some time ago (maybe 10 years). I could be wrong but thought at the time this was awfully small. Since that wasn't the issue I was looking at I put the thought aside and continued looking for another field. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Anyone Using IBM 3592, Sun/STK 9940,
In a recent note, Russell Witt said: Date: Wed, 29 Mar 2006 18:57:47 -0600 As others have stated, the file-limit was never 255. It used to be (as Bruce indicated) and still is if you use JCL. However, if you do OPEN TYPE=J Sigh! Conway's law at it's most pernicious? Don't these departments within IBM communicate with each other? In a recent note John Eells said: z/OS R7: Extend Tape Table of Contents (TTOC) records to raise the DFSMShsm limit on the number of data sets per tape to support more than 330,000 data sets per volume. This can provide better Kind of wonder why that limit. Is that the basic capacity of the tape, rather than the size of a field in a control block? And JCL will catch up when? (And what about DYNALLOC?) Sounds like material for a Requirement. -- gil -- StorageTek INFORMATION made POWERFUL -- 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: Delete VSAM file flagged as Open
Jim Willingham wrote: I have a VSAM file that is used in CICS. The region is down and we are trying to restore the file but it will not restore because it is flagged as open for update by multiple users. How do you correct this? Normally one would use IDCAMS or TSO VERIFY command to reset the dataset's OPEN status - or any usage of the file that causes an OPEN should also do an auto-verify (with possible except of OPEN by a COBOL program with no status checking, which may cause the program to terminate with no CLOSE of the file, which again leaves file in an OPEN state). -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Systems Programmer Levels Justification
Tom Schmidt wrote: On Tue, 28 Mar 2006 14:43:05 -0600, Desi de la Garza wrote: We are in the process of justifying the requirement of having multiple levels of SysProg job titles depending on experience and knowledge. At the same time provide management with information as to why SysProgs are higher salaried than application programmers. They are at a loss as to why that is. Weird that they do not question why a network tech makes more than the applications also. One reason to do so is because other employers behave that way and if your organization does NOT behave that way you will begin to lose your more experienced SysProgs to them (at their higher pay ranges). So your management will either have to go along with the trend or be in a continuous training mode. (Steve will love that idea!) As to why the salary differences by position: Consider which group answers the questions and which group asks them. You generally pay more to the guy with the answers. (That's a key premise behind consulting anyway. Right answers are usually worth more, but sometimes it is a function of presentation and not content so much. That is a key premise of marketing.) -- Tom Schmidt Madison, WI ... A number of reasons for the SysProg salary differential: (1)a SysProg needs a large amount of specialized training to handle issues on hardware and operating system configuration which application programmers never have to consider; (2)a SysProg needs the ability to resolve those problems that application programmers are unable to resolve, including cross-application and performance problems which application programmers may be ill-equipped to address; (3)a SysProg needs a large amount of innate curiosity, an ability to read with understanding many boring and arcane hardware and systems manuals and documentation, and an ability to do independent research to acquire the expertise to do (1) and (2) competently; (4)if you don't pay enough to attract and retain good SysProgs that are sufficiently competent at (1)-(3), then those you end up with are more likely to make mistakes that kill not just one application system, but the entire Operating System and all application systems. In the worst cases everything could be down for hours or even days. A marginal SysProg has many more opportunities than an application programmer to make a mistake that could put the entire company out of business. -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Alternative to mvsqr, was: Bringing the fun back to z/OS - new course
Hi colleagues, snip We are in the process of moving the UNIX apps to Linux under VM, where they can use the other type of processors and save us a lot of software costs (BMC is killing us, followed by CA.) snip I was asked to find out whether there exist z/OS based products from IBM or 3rd parties that provide similar content functionality. Any idea? TIA, Arthur -- 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: Alternative to mvsqr, was: Bringing the fun back to z/OS - new course
Arthur, Similar functionality to which products? Arthur Fichtl wrote: Hi colleagues, snip We are in the process of moving the UNIX apps to Linux under VM, where they can use the other type of processors and save us a lot of software costs (BMC is killing us, followed by CA.) snip I was asked to find out whether there exist z/OS based products from IBM or 3rd parties that provide similar content functionality. Any idea? TIA, Arthur -- 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 -- Rich Smrcina VM Assist, Inc. Main: (262)392-2026 Cell: (414)491-6001 Ans Service: (360)715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2006 - Chattanooga, TN - April 7-11, 2006 -- 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
