Re: ACIF question - variable length input
The length in the length field in the structure field introducer must match the number of bytes in the record, including this length field, excluding the X'5A' byte. The length of the record (RDW) is this length plus 1 for the X'5A'. So, for the VB format, the length must be consistent. Adjust your program to fill in the actual length when writing VB records instead of keeping the FB length (Why would you want to write VB records instead of FB record if not to save space in the file?) -- Peter Hunkeler CREDIT SUISSE AG -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DB/2 V7 and z/OS 1.11
Daniel Allen wrote: We had to retro-fit one LPAR from z/OS 1.10 to z/OS 1.9 so we could re- claim data. What happened to 'backward compatibility'? Or did I missed something here? Actually what I want also to know is, what is in the newer releases of z/OS or what is in the old DB2 that prevent co-operation? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Multi-Level Aliases and System Software
John Eells wrote: Given a couple of fairly recent threads, it's probably a good idea to add, before anyone panics, that we do *not* intend to remove support for MLA as far as I know. Sheesh, you murderer, I'm already dying from panic... ;-D For the survivors: start a new rumour thread: 'MLA is dead - support to be withdrawn on z/OS v1.13' April 1 is near enough for some hoax threads... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
VTS Migration
Currently starting a VTS migration to a B20 and have been doing a lot of RTFM'ing in preperation but there doesn't seem to be much out there in regards to the RMM - OAM - z/OS side of things. I have put a rough plan together, which is looking reasonably good, but it would be nice to see any documentation (i.e. IBM guides) to clear a few points up and ensure that I'm actually doing it correctly! One area I'm worried up is that we want to keep the same esoteric device name, i.e. VTS so that we don't have to change all the JCL. Any pointers to where I should be looking would be most grateful. Thanks, Seb. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTS Migration
I guess that will depend. Are you doing a push-pull? So only one Tape Type will be active at one time? Are your ACS routines reviewed? I did not change my esoteric name, only the device addresses defined to that esoteric when I moved from STK to VTS. So TAPE had B00-B25 in it and I had removed the Af0-Aff. But it was always TAPE. Lizette Currently starting a VTS migration to a B20 and have been doing a lot of RTFM'ing in preperation but there doesn't seem to be much out there in regards to the RMM - OAM - z/OS side of things. I have put a rough plan together, which is looking reasonably good, but it would be nice to see any documentation (i.e. IBM guides) to clear a few points up and ensure that I'm actually doing it correctly! One area I'm worried up is that we want to keep the same esoteric device name, i.e. VTS so that we don't have to change all the JCL. Any pointers to where I should be looking would be most grateful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Entry point for a Mainframe?
A Wheeler writes: a lot of the software as service ... and cloud computing ... very analogous to oldtime online timesharing ... is partially being driven by super-efficient megadatacenters (coupled with ubiquitous high-speed connectivity) Agreed. There are a lot of similarities, but one difference is the ubiquity of the Internet. It's really an accident of history (telco monopolies) that the price-per-carried bit collapsed *after* the prices of CPU and storage did. So we went through (suffered?) an intermediate phase when computing architectures were principally constrained by high priced long distance networking (the PC revolution and then Client/Server). It's interesting viewing those phases through the rear view mirror. In many ways it's back to the future now. Of course, each phase leaves its marks, some of which last forever. To carry this thread back to the MP3000, it's worth noting that the z10 BC is an extremely Internet-friendly server. The MP3000 (sadly) wasn't. The z10 BC supports huge SSL handshake rates and high volume IPSec with its crypto capabilities, 64-bit addressing (for multiple big Java application serving and Apache HTTP z/OS workloads), highly concentrated Linux virtualization, a raft of modern Internet-related software (WebSphere Commerce, WebSphere Portal, WebSphere Dashboard Framework, Lotus ActiveInsight, etc., etc.), the latest (and uncompromised) OSA-Express functions, remote Internet-friendly hardware console support, and so on. Regardless of the size of business, it's a far better server for this new reality of the ubiquitous Internet. CNNIC is a good example of a new Internet-related customer, and they came into the fold with a z9 BC: http://www.ibm.com/press/us/en/pressrelease/27768.wss They wouldn't have been able to join the community of mainframe owners with an MP3000 (even solution time-adjusted to 1999), unfortunately. - - - - - Timothy Sipples IBM Consulting Enterprise Architect for New, Advanced, and/or Innovative Solutions (VCT) Based in Singapore Serving the Growth Markets E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Plans to Discontinue REDBOOK Series
We IBMers are officially denying it. Can we move on, now? Almost. :-) One more point: there are always a lot of crazy rumors floating around. For example, just the other day I heard a rumor that IBM would enter the hot dog manufacturing business in 2011. OK, no, I didn't hear that, but I could have. There aren't enough minutes to refute all wacky rumors. It's just impossible and ultimately pointless to attempt. In short, non-denials are certainly *not* confirmations. - - - - - Timothy Sipples IBM Consulting Enterprise Architect for New, Advanced, and/or Innovative Solutions (VCT) Based in Singapore Serving the Growth Markets E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FDR/UPSTREAM for Open Systems on zOS
On Wed, 10 Mar 2010 05:18:22 -0800, bob molerio mole...@yahoo.com wrote: Is anyone using this to backup open systems clients? Looked at all the products a number of years ago and chose IBM TSM for z/OS because of various reasons. But my choice may have been abad one now IBM has decided to not support the TSM Server on z/OS any more. The advantages of z/OS are many for us especially as far as DR goes. My second choice was FDR's product though. Back then a number of things bothered me about their implementation. 1. The pricing was on the amount of data to be stored. This causes one in the government to have to over buy to make sure you do not suddenly run out. 2. The storage of files on tapes had to be really thought though because of mixed expiration of data. The tape had to be kept around until the last bit of data on the tape expired. There was no way to take 2 or more tapes and pull all the non-expired data off to make one new one. This presented a challenge. 3. On had to keep track of what was on what tape in the case of what was current. It was not going to as straight forward as the model TSM has which is very much akin to HSM for Open Systems. I have told IBM people who are running TSM for z/OS are not going to suddenly switch it over and host TSM on Windows, etc, because of the various operational issues, etc and also losing the notion of leveraging existing ATLs, VTS's, Automated Operations, skill sets, Automated Scheduling, etc. But they contend that they can get DB2 to perform very well on z/OS to handle the TSM database therefore it should not be hosted any more on z/OS. I will be taking a 2nd look at FDR/Upstream to learn if it is any easier to keep track of files on all those tapes and also about pricing models. Oh yes, am told TSM for z/OS will be around stabilized at V5 and supported until around 2013. So folks should be making other plans long before they pull the plug. jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Plans to Discontinue REDBOOK Series
Timothy Sipples wrote: ... just the other day I heard a rumor that IBM would enter the hot dog manufacturing business in 2011. More rumours and jokes about IBM... http://www.snopes.com/humor/business/mouse.asp http://www.snopes.com/computer/program/stroustrup.asp http://www.snopes.com/business/genius/salted.asp http://www.snopes.com/quotes/kenolsen.asp And then there is my favourite rumour... ;-D Apparently IBM decided to have some parts manufactured in Japan as a trial project. In the specifications, they set out that they will accept three defective parts per 10,000. When the delivery came in there was an accompanying letter. We, Japanese people, had a hard time understanding North American business practices. But the three defective parts per 10,000 have been separately manufactured and have been included in the consignment. Hope this pleases you. . Today's rumour: today is Friday! ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
EPHEMERAL UDP SOURCE PORTS
hello Vtam-fellows, we had several outages to EnterpriseExtender customers after migrating to z/OS 1.10. Everyone who wants to migrate to z/OS 1.10 (or 1.9 or 1.11) and is using EnterpriseExtender should have a look at: OA31452 TOLERATE USE OF EPHEMERAL UDP SOURCE PORTS FOR EE UA51894 569511701CLOSED 1A0 COR 1000 UA51895 569511701CLOSED 1B0 COR 1000 UA51896 569511701CLOSED 190 COR 1000 regards Juergen Keller -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Plans to Discontinue REDBOOK Series
Yes, the Six Sigma standard, go out 6 standard deviations from the mean instead of the standard 3, is 3.4 defects in a million, instead of 1 in 370. The Japanese definitely needed to create some defects. Six Sigma is a recognized optimizing technique to achieve CMMI (Capability Maturity Model Integration) level 5, nirvana, which model incidentally can be traced back originally to a Bmer, Watts Humphery. On Thu, Mar 11, 2010 at 8:31 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Timothy Sipples wrote: ... just the other day I heard a rumor that IBM would enter the hot dog manufacturing business in 2011. More rumours and jokes about IBM... http://www.snopes.com/humor/business/mouse.asp http://www.snopes.com/computer/program/stroustrup.asp http://www.snopes.com/business/genius/salted.asp http://www.snopes.com/quotes/kenolsen.asp And then there is my favourite rumour... ;-D Apparently IBM decided to have some parts manufactured in Japan as a trial project. In the specifications, they set out that they will accept three defective parts per 10,000. When the delivery came in there was an accompanying letter. We, Japanese people, had a hard time understanding North American business practices. But the three defective parts per 10,000 have been separately manufactured and have been included in the consignment. Hope this pleases you. . Today's rumour: today is Friday! ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTS Migration
You got me on the push-pull bit :-) That is pretty much what I plan to do by giving the new VTS a different range of addresses but I need to migrate all the existing data over (HSM, etc.) so I would have problems with UNIT=TAPE as I would not be able to determine into which VTS the data is being written into. We need to run with them both concurrently for a short period of time. Thanks, Seb. On Thu, 11 Mar 2010 07:56:12 -0500, Lizette Koehler stars...@mindspring.com wrote: I guess that will depend. Are you doing a push-pull? So only one Tape Type will be active at one time? Are your ACS routines reviewed? I did not change my esoteric name, only the device addresses defined to that esoteric when I moved from STK to VTS. So TAPE had B00-B25 in it and I had removed the Af0-Aff. But it was always TAPE. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTS Migration
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sebastian Welton Sent: Thursday, March 11, 2010 8:20 AM To: IBM-MAIN@bama.ua.edu Subject: Re: VTS Migration You got me on the push-pull bit :-) That is pretty much what I plan to do by giving the new VTS a different range of addresses but I need to migrate all the existing data over (HSM, etc.) so I would have problems with UNIT=TAPE as I would not be able to determine into which VTS the data is being written into. We need to run with them both concurrently for a short period of time. Thanks, Seb. Aren't the VTSes managed by SMS? If so, then the UNIT= is not very important. You have two separate libraries. Make a new Storage Group for the new library. Now, in the STORGRUP ACS routine, assign the new STORGRUP where you current assign the old STORGRUP value. Presto! Everything that went to the old VTS, now goes to the new VTS. This does __NOT__ affect access to existing tape data in the old VTS as it is still in the old STORGRUP, which is assigned to the old VTS library. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Entry point for a Mainframe?
To repeat an already over-used analogy, there really are trucks in this world, and they're quite popular, even if they do consume only diesel fuel. There are also bicycles. If you're starting a bicycle messenger service, buy a bicycle. There's nothing wrong with that. Thank goodness there are different vehicles for different mission profiles. To extend the above analogy, you can buy Fedex, UPS, or USPS service and avoid renting, leasing, or owning your own trucks or bicycles. Actually, UPS started on bicycles in the far Northwest, then went to motor bycycles, then trucks which, until sometime in the 70's or 80's, they actually manufactured themselves. Finally they went to jets with one of the largest fleets of jets in the world, thousands. I guess somewhere along the line, when they went to jets, they decided to stop manufacturing their delivery equipment. They were private until somewhere around Y2K. When they went public, they were very generous with their employees, many of whom became instant millionaires overnight. It is amazing what a little efficiency, courtesy, and consideration to their employees, their business model, can do in such a mundane world as package delivery. On Wed, Mar 10, 2010 at 8:47 PM, Timothy Sipples timothy.sipp...@us.ibm.com wrote: Steve Thompson writes: And the power requirements for this z10? Can it be plugged into a wall beside my desk lamp on a 30A circuit? No. So you can deduct a point for that if you like. That said, you wouldn't be able to dry your laundry in most U.S. homes if you insisted on 120 volts only. :-) To repeat an already over-used analogy, there really are trucks in this world, and they're quite popular, even if they do consume only diesel fuel. There are also bicycles. If you're starting a bicycle messenger service, buy a bicycle. There's nothing wrong with that. Thank goodness there are different vehicles for different mission profiles. Now, I happen to think that the System z10 BC as a (more) entry-level mainframe is in every way superior to the Multiprise 3000, with perhaps two exceptions: physical space (which includes weight) and the electric circuit requirement. In every other respect I can think of, it scores a lot higher. (Including economics, which is typically a nice way to compensate for those other two criteria.) If you're asking, Could the System z10 BC be even better? -- in the categories of space and electric circuit requirements, for example -- well sure, theoretically. But then it might be compromised in other dimensions. Again, I'm very fond of the MP3000, but its design required a number of compromises. By the way, an awful lot of small businesses are opting for Software as a Service offerings and choosing not to own or host their own servers, of any type. If you want a zero-footprint z/OS machine -- that sure beats the MP3000! -- it's available. To extend the above analogy, you can buy Fedex, UPS, or USPS service and avoid renting, leasing, or owning your own trucks or bicycles. If the world is already heading in that SaaS direction -- and it sure looks that way -- then a z10 footprint makes even more sense. Also (and you alluded to it, Steve), has anyone visited a data center lately? Think about those 1980s narratives: Years ago, the computer was so big, it filled an entire room Well, nowadays it's worse: The racks of servers are so numerous, they fill football fields, consume prodigious amounts of electricity, and run so hot it's getting impossible to cool them Progress! :-) The smallest, coolest running server in most data centers is the System z10. It's the *answer* to server sprawl. And perhaps you'd be surprised how many small businesses suffer from server sprawl. - - - - - Timothy Sipples IBM Consulting Enterprise Architect for New, Advanced, and/or Innovative Solutions (VCT) Based in Singapore Serving the Growth Markets E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTS Migration
How are your naming standards? Is your current library controlled though SMS? You can control all your new tape allocations through your SMS routines and don't have to worry about or change your esoterics at all. You may want to have your new tape addresses added to your esoterics. I didn't really sweat that part. I've done 2 VTS migrations to date and I'll probably be starting the 3rd one the end of this/next month depending on some hardware decisions. Have you considered how you're moving your old data over to the new library? I've used OpenTec's TapeCopy product for the last 2 moves and plan on using it for the next move too. It works great - keeps all the CA1 information in-sync - multi-volume, stacked, cataloged/uncataloged - it handled it all. I'm sure others can say the same about other products. Moving the new allocations over to the new library is pretty straight-forward - moving the old data over can be a bit more tricky and you'll need to do some careful planning to get it done. ddk You got me on the push-pull bit :-) That is pretty much what I plan to do by giving the new VTS a different range of addresses but I need to migrate all the existing data over (HSM, etc.) so I would have problems with UNIT=TAPE as I would not be able to determine into which VTS the data is being written into. We need to run with them both concurrently for a short period of time. Thanks, Seb. On Thu, 11 Mar 2010 07:56:12 -0500, Lizette Koehler stars...@mindspring.com wrote: I guess that will depend. Are you doing a push-pull? So only one Tape Type will be active at one time? Are your ACS routines reviewed? I did not change my esoteric name, only the device addresses defined to that esoteric when I moved from STK to VTS. So TAPE had B00-B25 in it and I had removed the Af0-Aff. But it was always TAPE. Lizette 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Multi-Level Aliases and System Software
Let me guess The Redbook on MLA got cancelled and started this whole mess? Just kidding folks ... Beat your head against the wall, it feels good when you stop. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Elardus Engelbrecht Sent: Thursday, March 11, 2010 6:03 AM To: IBM-MAIN@bama.ua.edu Subject: Re: [IBM-MAIN] Multi-Level Aliases and System Software John Eells wrote: Given a couple of fairly recent threads, it's probably a good idea to add, before anyone panics, that we do *not* intend to remove support for MLA as far as I know. Sheesh, you murderer, I'm already dying from panic... ;-D For the survivors: start a new rumour thread: 'MLA is dead - support to be withdrawn on z/OS v1.13' April 1 is near enough for some hoax threads... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Entry point for a Mainframe?
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. timothy.sipp...@us.ibm.com (Timothy Sipples) writes: Agreed. There are a lot of similarities, but one difference is the ubiquity of the Internet. It's really an accident of history (telco monopolies) that the price-per-carried bit collapsed *after* the prices of CPU and storage did. So we went through (suffered?) an intermediate phase when computing architectures were principally constrained by high priced long distance networking (the PC revolution and then Client/Server). It's interesting viewing those phases through the rear view mirror. In many ways it's back to the future now. re: http://www.garlic.com/~lynn/2010e.html#78 Entry point for a Mainframe? recent post/thread in tcp/ip n.g. http://www.garlic.com/~lynn/2010e.html#73 NSF to Fund Future Internet Architecture (FIA) and similar comments in this (mainframe) post/thread http://www.garlic.com/~lynn/2010e.html#64 LPARs: More or Less? about telcos having very high fixed costs/expenses and significant increase in available bandwdith with all the dark fiber in the ground represented difficult chicken/egg obstacle (disruptive technology). The bandwidth hungry applications wouldn't appear w/o significant drop in use charges (but could still take a decade or more) ... and until the bandwidth hungry applications appeared, any significant drop in the useage charges would mean that they would operate deeply in the red during the transition. in the mid-80s, the hsdt project had a very interesting datapoint with communication group ... where we were deploying and supporting T1 and faster links. http://www.garlic.com/~lynn/subnetwork.html#hsdt The communication group then did a corporate study that claimed that there wouldn't be customer use of T1 until mid-90s (aka since they didn't have product that supported T1, the study supported customers not needing T1 for another decade). The problem was that 37x5 boxes didn't have T1 support ... and so what the communication group studied was fat pipes ... support for being able to operate multiple 56kbit links as single unit. For their T1 conclusions they plotted the number of fat pipes with 2, 3, 4, ..., etc 56kbit links. They found that number of fat pipes dropped off significantly at four or five 56kbit links and there were none above six. There is always the phrase about statistics lie ... well, what the communication group didn't appear to realize was that most telcos had tariff cross-over about five or six 56kbit links being about the same as a single T1 link. What they were seeing, was when customer requirement reached five 56kbit links ... the customers were moving to single T1 link supported by other vendors products (which was the reason for no fat pipes above six). The communication groups products were very oriented towards to the legacy dumb terminal paradigm ... and not the emerging peer-to-peer networking operation. In any case, a very quick, trivial survey by HSDT turned up 200 customers with T1 links (as counter to the communication group survey that customers wouldn't be using T1s until mid-90s ... because they couldn't find any fat pipes with more than six 56kbit links). this is analogous to communication group defining T1 as very high speed in the same period (in part because their products didn't support T1) ... mentioned in this post: http://www.garlic.com/~lynn/2010e.html#11 Crazed idea: SDSF for z/Linux the various internal politics all contributed to not letting us bid on the NSFNET backbone RFP ... even when the director of NSF wrote a letter to corporation ... and there were observations that what we already had running was at least five years ahead of RFP bid responses (to build something new). misc. old NSFNET related email from the period http://www.garlic.com/~lynn/lhwemail.html#nsfnet -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Entry point for a Mainframe?
Also (and you alluded to it, Steve), has anyone visited a data center lately? Think about those 1980s narratives: Years ago, the computer was so big, it filled an entire room Well, nowadays it's worse: The racks of servers are so numerous, they fill football fields, consume prodigious amounts of electricity, and run so hot it's getting impossible to cool them Progress! :-) The smallest, coolest running server in most data centers is the System z10. It's the *answer* to server sprawl. And perhaps you'd be surprised how many small businesses suffer from server sprawl. Actually a previous client, a large Wall St investment house that survived the recent crisis, has so many blade servers in its data center they can't fit anymore in. So they have a pilot project to bring them up on LINUX under z/VM. Hurray for server consolidation, finally, a software solution beating a hardware solution. Amen On Thu, Mar 11, 2010 at 9:43 AM, Anne Lynn Wheeler l...@garlic.comwrote: The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. timothy.sipp...@us.ibm.com (Timothy Sipples) writes: Agreed. There are a lot of similarities, but one difference is the ubiquity of the Internet. It's really an accident of history (telco monopolies) that the price-per-carried bit collapsed *after* the prices of CPU and storage did. So we went through (suffered?) an intermediate phase when computing architectures were principally constrained by high priced long distance networking (the PC revolution and then Client/Server). It's interesting viewing those phases through the rear view mirror. In many ways it's back to the future now. re: http://www.garlic.com/~lynn/2010e.html#78 Entry point for a Mainframe? recent post/thread in tcp/ip n.g. http://www.garlic.com/~lynn/2010e.html#73 NSF to Fund Future Internet Architecture (FIA) and similar comments in this (mainframe) post/thread http://www.garlic.com/~lynn/2010e.html#64 LPARs: More or Less? about telcos having very high fixed costs/expenses and significant increase in available bandwdith with all the dark fiber in the ground represented difficult chicken/egg obstacle (disruptive technology). The bandwidth hungry applications wouldn't appear w/o significant drop in use charges (but could still take a decade or more) ... and until the bandwidth hungry applications appeared, any significant drop in the useage charges would mean that they would operate deeply in the red during the transition. in the mid-80s, the hsdt project had a very interesting datapoint with communication group ... where we were deploying and supporting T1 and faster links. http://www.garlic.com/~lynn/subnetwork.html#hsdt The communication group then did a corporate study that claimed that there wouldn't be customer use of T1 until mid-90s (aka since they didn't have product that supported T1, the study supported customers not needing T1 for another decade). The problem was that 37x5 boxes didn't have T1 support ... and so what the communication group studied was fat pipes ... support for being able to operate multiple 56kbit links as single unit. For their T1 conclusions they plotted the number of fat pipes with 2, 3, 4, ..., etc 56kbit links. They found that number of fat pipes dropped off significantly at four or five 56kbit links and there were none above six. There is always the phrase about statistics lie ... well, what the communication group didn't appear to realize was that most telcos had tariff cross-over about five or six 56kbit links being about the same as a single T1 link. What they were seeing, was when customer requirement reached five 56kbit links ... the customers were moving to single T1 link supported by other vendors products (which was the reason for no fat pipes above six). The communication groups products were very oriented towards to the legacy dumb terminal paradigm ... and not the emerging peer-to-peer networking operation. In any case, a very quick, trivial survey by HSDT turned up 200 customers with T1 links (as counter to the communication group survey that customers wouldn't be using T1s until mid-90s ... because they couldn't find any fat pipes with more than six 56kbit links). this is analogous to communication group defining T1 as very high speed in the same period (in part because their products didn't support T1) ... mentioned in this post: http://www.garlic.com/~lynn/2010e.html#11 Crazed idea: SDSF for z/Linux the various internal politics all contributed to not letting us bid on the NSFNET backbone RFP ... even when the director of NSF wrote a letter to corporation ... and there were observations that what we already had running was at least five years ahead of RFP bid responses (to build something new). misc. old NSFNET related email from the period http://www.garlic.com/~lynn/lhwemail.html#nsfnet --
electronic resources and books for learning Assembler?
I'm a totally blind programmer who needs to learn mainframe assembly. All the books that appear to be available were written before electronic publishing became popular. What resources are available in electronic format to teach myself assembler on the mainframe? A search of the popular electronic book sites with a programming focus such as http://www.safaribooksonline.com came up dry and IBM Redbooks doesn’t appear to have any introductory assembler material. Thanks for any info. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Plans to Discontinue REDBOOK Series
Sheesh, Timothy, see what you started? On Thu, Mar 11, 2010 at 7:31 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Today's rumour: today is Friday! ;-D Groete / Greetings Elardus Engelbrecht -- Rich Smrcina -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Plans to Discontinue REDBOOK Series
You get that off you GPS? . Today's rumour: today is Friday! ;-D -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Plans to Discontinue REDBOOK Series
Well, the OP should review what he started and why, and we all should consider preventing such a waste of bandwith and reading/replying time in the future. We got better things to do (at least I have) and for those who do have time for this, there are other fora . Kees. Rich Smrcina rsmrc...@gmail.com wrote in message news:72cc50701003110654j70c2c18fu13b19d51c081b...@mail.gmail.com... Sheesh, Timothy, see what you started? On Thu, Mar 11, 2010 at 7:31 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Today's rumour: today is Friday! ;-D Groete / Greetings Elardus Engelbrecht -- Rich Smrcina -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Concatenating SORTIN short LRECL DSN's with DD * input?
I have several short LRECL=45 DSN's to be sorted and I need to add one or two records by hand as DD * input. I tried the following, but SORT got a wrong length record error on SORTIN when I did: //SORTIN DD DISP=SHR,DSN=TSOUSER.LRECL45.FILE1 // DD DISP=SHR,DSN=TSOUSER.LRECL45.FILE2 // DD *,LRECL=45,BLKSIZE=45 ADDITIONAL RECORD DATA //* IER061A I/O ERR TSOUSERU,SORTDATA,JES ,I,SORTIN ,READ ,WRONG LEN RECRD TIA for pointing out whatever my error may be, or if there is some other method I should be using to add the one or two additional records. I know I can just create a one-record file of the same LRECL, but it just seems like overkill to me when DD * should just work here, shouldn't it? Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Entry point for a Mainframe?
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. gahe...@gmail.com (George Henke) writes: Actually a previous client, a large Wall St investment house that survived the recent crisis, has so many blade servers in its data center they can't fit anymore in. So they have a pilot project to bring them up on LINUX under z/VM. Hurray for server consolidation, finally, a software solution beating a hardware solution. re: http://www.garlic.com/~lynn/2010e.html#80 Entry point for a Mainframe? the claim was that in the 90s ... to have multiple applications co-exist in the same operating system required scarce, high-level skills (allocation, co-existance, capacity planning, etc) ... it was much easier and cheaper to throw hardware at the problem ... giving each application (and even application instance) its own dedicated hardware. rolling forward to couple years ago and organizations found themselves with thousands, tens of thousands, or even hundreds of thousands of these dedicated services ... all running at 5-10% utilization. virtualization, dynamic load balancing and some other technologies came together to support server consolidation (sometimes 10 or 20 to one running on essentially the identical hardware). part of the issue was that there was only very modest incremental skill level required for server consolidation (as compared to trying to getting lots of disparent applications to co-exist in the same system). lots of technologies are being pump into virtualization environment ... like dynamic migration of virtual machine to different hardware (even in different datacenters) for capacity reasons and/or continuous operation reasons. other posts in this thread: http://www.garlic.com/~lynn/2010e.html#68 Entry point for a Mainframe? http://www.garlic.com/~lynn/2010e.html#70 Entry point for a Mainframe? http://www.garlic.com/~lynn/2010e.html#71 Entry point for a Mainframe? http://www.garlic.com/~lynn/2010e.html#72 Entry point for a Mainframe? http://www.garlic.com/~lynn/2010e.html#78 Entry point for a Mainframe? -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTS Migration
As John mentioned, if your tapes are SMS manages then esoterics are not used, period. There is no need whatsoever to have an esoteric device name for SMS managed tape devices, they have no effect at all. If you use UNIT=TAPE, then the only component looking at that value is your ACS routines, device allocation is not using the UNIT value. Sebastian Welton sebast...@welton.de 3/11/2010 6:23 AM Currently starting a VTS migration to a B20 and have been doing a lot of RTFM'ing in preperation but there doesn't seem to be much out there in regards to the RMM - OAM - z/OS side of things. I have put a rough plan together, which is looking reasonably good, but it would be nice to see any documentation (i.e. IBM guides) to clear a few points up and ensure that I'm actually doing it correctly! One area I'm worried up is that we want to keep the same esoteric device name, i.e. VTS so that we don't have to change all the JCL. Any pointers to where I should be looking would be most grateful. Thanks, Seb. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concatenating SORTIN short LRECL DSN's with DD * input?
Hi Peter. It should work, even with empty files, but as stated in the DFSORT book ...be sure to supply RECFM, LRECL and BLKSIZE)... Hope this can help you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: electronic resources and books for learning Assembler?
Jared Stofflett wrote: I'm a totally blind programmer who needs to learn mainframe assembly. All the books that appear to be available were written before electronic publishing became popular. What resources are available in electronic format to teach myself assembler on the mainframe? A search of the popular electronic book sites with a programming focus such as http://www.safaribooksonline.com came up dry and IBM Redbooks doesnt appear to have any introductory assembler material. Thanks for any info. Did you try out Assembler-L, a discussion list for Mainframe Assembler? Please follow this link to join up: http://www.listserv.uga.edu/archives/asm370.html I'm sure there are very kind people there who can really help you out. All of the very best for you. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concatenating SORTIN short LRECL DSN's with DD * input?
On Thu, 11 Mar 2010 10:35:02 -0500, Farley, Peter x23353 wrote: I have several short LRECL=45 DSN's to be sorted and I need to add one TIA for pointing out whatever my error may be, or if there is some other method I should be using to add the one or two additional records. I know I can just create a one-record file of the same LRECL, but it just seems like overkill to me when DD * should just work here, shouldn't it? IDCAMS REPRO is pretty good at converting attributes (but I don't know if it will go longer - shorter), so with the attition of a job step you might be able to use a temporary DSN. JCL is no longer limited to Fixed 80, but, alas, the minimum remains 80. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Multi-Level Aliases and System Software
John, We use MLAs for two purposes. We have a SYS1.OMVS alias to ease deployment of z/OS upgrades. In a nutshell, we still haven't merged our master-catalog-per-image to a sysplex- common master, and we use SYS1 for version HFS' to keep them out of SMS- management. I know there are other ways, but this is easier for us for now. We also have MLAs for our shared SMP/E and z/OS installation datasets. Again, there are other ways, but this was the best solution for the neophobic. It allowed us to keep our existing naming standards and still access our non-shared SMP/E and installation data and our shared SMPE/E and installation data through separate catalogs. I know you didn't mention it specifically, but we also make extensive use of ALIAS with SYMBOLICRELATE for deployment of our ISV software, just in case IBM was thinking about dropping support for that, too (KIDDING!). Regards, Art Gutowski Ford Motor Company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Plans to Discontinue REDBOOK Series
'The first denial lends credence to a rumor' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concatenating SORTIN short LRECL DSN's with DD * input?
This is going to sound (and may well be) real dumb. But instead of // DD *,LRECL=45,BLKSIZE=45 try doing: // DD *,DCB=LRECL=45 I know those mean the same thing to the JCL intepreter. But the examples in the JCL manual all do it this way. And I wonder if the JES2 reader code looks for the DCB=. Also, for doing a fast scan in HASPRDR, be sure that there are no non-blank columns beyond column 45. It appears that HASPRDR keeps track of the longest record found in the input and saves that as the LRECL in the PDDB control block. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Farley, Peter x23353 Sent: Thursday, March 11, 2010 9:35 AM To: IBM-MAIN@bama.ua.edu Subject: Concatenating SORTIN short LRECL DSN's with DD * input? I have several short LRECL=45 DSN's to be sorted and I need to add one or two records by hand as DD * input. I tried the following, but SORT got a wrong length record error on SORTIN when I did: //SORTIN DD DISP=SHR,DSN=TSOUSER.LRECL45.FILE1 // DD DISP=SHR,DSN=TSOUSER.LRECL45.FILE2 // DD *,LRECL=45,BLKSIZE=45 ADDITIONAL RECORD DATA //* IER061A I/O ERR TSOUSERU,SORTDATA,JES ,I,SORTIN ,READ ,WRONG LEN RECRD TIA for pointing out whatever my error may be, or if there is some other method I should be using to add the one or two additional records. I know I can just create a one-record file of the same LRECL, but it just seems like overkill to me when DD * should just work here, shouldn't it? Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Migration of DFrmm to z/OS 1.11
Here is something to watch for. In going to z/OS 1.11 DFrmm MUST use dynamic exits. In our case, for a number of releases, our UX100 exit resided in a STEPLIB, not the LNKLST. When you go to z/OS 1.11 your UX100 exit library MUST be in the LNKLST. Regards Lorne Dudley Queen's University Kingston, Ontario CANADA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTS Migration
snip if your tapes are SMS manages then esoterics are not used, period. /snip This comment excludes HSM access. HSM does a pre call to SMS and won't allocate if the tape esoteric is not defined to MVS. Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FDR/UPSTREAM for Open Systems on zOS
I responded offline on the product, but this is basically what I said On the server side there is an agent that gets installed. That agent is the part that talks to upstream on the z/os server.I have brought up replacing the product several times and the windows staff go into a panic. All of the backup/tape processing is so automatic on the mainframe side it is foolproof. They don't have to mount tapes, keep track of them, etc. They just need to startup their GUI on the windows server and tell it what to do. Once a week we do full backups on the servers. Daily we do incremental. All of this backup is done to virtual tape (yep, the same Virtual tape ALL the z/os server jobs use). After the backups complete, we run an Upstream process to stack the backups. We get about 8 server backups on one TS1120 style tapes. So we don't ship off a single tape for each server to Iron Mountain. We keep the backups on a regular cycle for 60 days. Once a month we keep the backups (on certain servers) for a year. So during the normal process if someone needs a file restore, the windows admins just go into the GUI on their desktop select the file they want restored and restore it. The windows server talks to upstream, which gets the data from the virtual tape. No real human intervention required. When we do a Disaster Recover test (we got one next week) the windows server admins tell the z/os server admins which servers they need and in what order. The z/os admins then run a REGEN job against the stacked tape which rebuilds the backups in the upstream catalog. The windows admins then run their jobs. Basically to restore a windows server the restore parms are //. And they select newest to last full option and upstream does the rest. In DR, we are doing bare metal restores to unlike servers. We run IBM blades and large servers here and at DR it is either Dell or HP. If and when then z/os server goes away, I would just switch to the upstream server that runs on distributed platforms. As far as fast goes, I think it is just a matter of your tape drive speed. When we went from 9840A's to TS1120's, I think a large server restore took about 20 minutes. The same process goes for our zFS dataset backups. Dennis -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Jim Marshall Sent: Thursday, March 11, 2010 5:19 AM To: IBM-MAIN@bama.ua.edu Subject: Re: FDR/UPSTREAM for Open Systems on zOS On Wed, 10 Mar 2010 05:18:22 -0800, bob molerio mole...@yahoo.com wrote: Is anyone using this to backup open systems clients? Looked at all the products a number of years ago and chose IBM TSM for z/OS because of various reasons. But my choice may have been abad one now IBM has decided to not support the TSM Server on z/OS any more. The advantages of z/OS are many for us especially as far as DR goes. My second choice was FDR's product though. Back then a number of things bothered me about their implementation. 1. The pricing was on the amount of data to be stored. This causes one in the government to have to over buy to make sure you do not suddenly run out. 2. The storage of files on tapes had to be really thought though because of mixed expiration of data. The tape had to be kept around until the last bit of data on the tape expired. There was no way to take 2 or more tapes and pull all the non-expired data off to make one new one. This presented a challenge. 3. On had to keep track of what was on what tape in the case of what was current. It was not going to as straight forward as the model TSM has which is very much akin to HSM for Open Systems. I have told IBM people who are running TSM for z/OS are not going to suddenly switch it over and host TSM on Windows, etc, because of the various operational issues, etc and also losing the notion of leveraging existing ATLs, VTS's, Automated Operations, skill sets, Automated Scheduling, etc. But they contend that they can get DB2 to perform very well on z/OS to handle the TSM database therefore it should not be hosted any more on z/OS. I will be taking a 2nd look at FDR/Upstream to learn if it is any easier to keep track of files on all those tapes and also about pricing models. Oh yes, am told TSM for z/OS will be around stabilized at V5 and supported until around 2013. So folks should be making other plans long before they pull the plug. jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at
Re: ACIF question - variable length input
Peter is correct. Structured fields carry their own length. They can be carried in fixed-length fields (there is a bit in the structured field introducer that indicates the record is padded). This is inefficient for files that are fully-composed (ie., that are complete documents or objects containing only structured fields). In z/OS or VSE, a MO:DCA (AFP) variable-length file consists of RDW, x'5A' (usually--identifies structured fields to the spooler), 2-byte length (excludes the x'5A'), and the remainder of the record. ACIF checks the record length in the RDW against the structured field length (plus the x'5A' if present). If the padding flag is off (the normal case), then the record length must match as above or ACIF issues the APK114S message. Howard Turetzky Advanced Technical Support (and former ACIF lead developer) InfoPrint Solutions Company howard.turet...@infoprint.com On Wed, 10 Mar 2010 17:15:12 -0700, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: So we have ACIF working if the input is a fixed length dataset. If we switch to a variable length dataset it works only if the x'5A' records are padded with spaces so that those records are the maximum LRECL for that file. For other lines it handles it fine if they are shorter than the maximum LRECL. z/OS and VSE both exhibit this behavior. Is this documented somewhere? Seems bizarre. If I use a VB file where the 5A records are not padded with spaces I get the following messages: APK114S DATA IN AN INPUT RECORD OR RESOURCE IS INVALID: RDW LENGTH DOES NOT AGREE WITH LENGTH IN STRUCTURED FIELD INTRODUCER. APK117S DATA IN AN INPUT RECORD OR RESOURCE IS INVALID: LENGTH INDICATED IN THE STRUCTURED FIELD INTRODUCER IS INCORRECT FOR IMM STRUCTURED FIELD. If my program writes to the output queue and I then use SDSF XDC to copy it to a (VBA) dataset it automatically keeps the 5A records space padded but all of the others are not. But if I write to the dataset directly I have to change my program to strip trailing spaces on all records except for the 5A records. Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTS Migration
True, but all you have to do is stop telling HSM to use a worthless esoteric. John Kelly john_j_ke...@ao.uscourts.gov 3/11/2010 11:00 AM snip if your tapes are SMS manages then esoterics are not used, period. /snip This comment excludes HSM access. HSM does a pre call to SMS and won't allocate if the tape esoteric is not defined to MVS. Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: electronic resources and books for learning Assembler?
Maybe this could be a good start http://www.billqualls.com/assembler/index.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Plans to Discontinue REDBOOK Series
If this was a forum instead of a listserv, an admin could have locked the topic and we could have moved on a long time ago. Oh, and that would also save everyone the trouble of snipping old posts, etc., from their messages, and save us from reading diatribes about replies at the top vs. replies at the bottom, and so on... -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Vernooij, CP - SPLXM wrote: Well, the OP should review what he started and why, and we all should consider preventing such a waste of bandwith and reading/replying time in the future. We got better things to do (at least I have) and for those who do have time for this, there are other fora . Kees. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concatenating SORTIN short LRECL DSN's with DD * input?
Peter Farley wrote on 03/11/2010 07:35:02 AM:
I have several short LRECL=45 DSN's to be sorted and I need to add one
or two records by hand as DD * input. I tried the following, but SORT
got a wrong length record error on SORTIN when I did:
//SORTIN DD DISP=SHR,DSN=TSOUSER.LRECL45.FILE1
// DD DISP=SHR,DSN=TSOUSER.LRECL45.FILE2
// DD *,LRECL=45,BLKSIZE=45
ADDITIONAL RECORD DATA
//*
IER061A I/O ERR TSOUSERU,SORTDATA,JES ,I,SORTIN ,READ ,WRONG LEN
RECRD
TIA for pointing out whatever my error may be, or if there is some other
method I should be using to add the one or two additional records. I
know I can just create a one-record file of the same LRECL, but it just
seems like overkill to me when DD * should just work here, shouldn't
it?
Hmmm. The only way I could get this to work with DFSORT was to use
LRECL=45 input files created with RECFM=F and BLKSIZE=45, so they would
match the attributes of the DD *, LRECL=45,BLKSIZE=45 statement
(which I assume is given RECFM=F by default). RECFM=FB for the
input data sets gave me a system ICE020I 001-1 error.
RECFM=FB on the DD * statement gave me a JCL error.
So it appears creating the input data sets with
RECFM=F is the only way to get the system to let this work.
I couldn't get this to work with DFSORT no matter what I did.
The WER061A message indicates you're using Syncsort, not DFSORT, but I
think they would both get the same result.
How about using TRAILER1 to add the additional records at the end of the
output file:
//SORTIN DD DISP=SHR,DSN=TSOUSER.LRECL45.FILE1
// DD DISP=SHR,DSN=TSOUSER.LRECL45.FILE2
...
//SYSIN DD *
...
OUTFIL REMOVECC,
TRAILER1=('ADDITIONAL RECORD 1 DATA',/,
'ADDITIONAL RECORD 2 DATA')
Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
= DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Entry point for a Mainframe?
From: Anne Lynn Wheeler l...@garlic.com To: IBM-MAIN@bama.ua.edu Sent: Thu, March 11, 2010 8:43:50 AM Subject: Re: Entry point for a Mainframe? SNIP The communication group then did a corporate study that claimed that there wouldn't be customer use of T1 until mid-90s (aka since they didn't have product that supported T1, the study supported customers not needing T1 for another decade). The problem was that 37x5 boxes didn't have T1 support ... and so what the communication group studied was fat pipes ... support for being able to operate multiple 56kbit links as single unit. For their T1 conclusions they plotted the number of fat pipes with 2, 3, 4, ..., etc 56kbit links. They found that number of fat pipes dropped off significantly at four or five 56kbit links and there were none above six. There is always the phrase about statistics lie ... well, what the communication group didn't appear to realize was that most telcos had tariff cross-over about five or six 56kbit links being about the same as a single T1 link. What they were seeing, was when customer requirement reached five 56kbit links ... the customers were moving to single T1 link supported by other vendors products (which was the reason for no fat pipes above six). The communication groups products were very oriented towards to the legacy dumb terminal paradigm ... and not the emerging peer-to-peer networking operation. In any case, a very quick, trivial survey by HSDT turned up 200 customers with T1 links (as counter to the communication group survey that customers wouldn't be using T1s until mid-90s ... because they couldn't find any fat pipes with more than six 56kbit links). this is analogous to communication group defining T1 as very high speed in the same period (in part because their products didn't support T1) ... mentioned in this post: http://www.garlic.com/~lynn/2010e.html#11 Crazed idea: SDSF for z/Linux the various internal politics all contributed to not letting us bid on the NSFNET backbone RFP ... even when the director of NSF wrote a letter to corporation ... and there were observations that what we already had running was at least five years ahead of RFP bid responses (to build something new). misc. old NSFNET related email from the period http://www.garlic.com/~lynn/lhwemail.html#nsfnet Ann In the mid 70's we had a T1 and we muxed it and IIRC we had 1 256K chunk and another chunk (sorry do not remember the speed) connected up to our 3745 and it worked really well (except a really strange bug which took us with the help of chance to figure out what the issue was). We were exercising it and kept it busy at least 20 out of 24 hours a day. I vaguely remember talking about the bug with IBM at the time (we were a small minority user of something like this at the time as IBM apparently only had a few people that seemed to know this part of NCP). Its not too surprising I guess that IBM really did not support a full T1 but if my memory (its iffy here) is correct it had something to do with the speed of the 3745 as to why IBM couldn't support it. SInce memory fades with time and I only remember small pieces we did seem to be on the bleeding edge at that time. Our bug turned out to not to have anything to do with NCP (per se) but I think if IBM would have had more experience they would have helped us find the issue sooner. IIRC there was semi documented information about lic weights (???) and you had to read it closely or you ended up with bad information. Sorry about the sketchiness but we are talking 35 years ago. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA Easytrieve replacement
Most mainframe shops own File/AID. This has both an online and batch element to it. File/AID batch is very powerful and we have replaced many of our Easytrieve jobs with it. It performs better (less CPU) and is far easier to maintain. even some of our junior team members are proficient in File/AID batch. Have a look into your tools portfolio. If you have File/AID then it's a no brainer. Regards. Simone. IT - Finance Systems UK On Tue, Feb 16, 2010 at 4:31 PM, Greg Shirey wgshi...@benekeith.com wrote: If anyone has replaced CA-Easytrieve at their shop and is willing to share details about what product was chosen and how the replacement performs in comparison to Easytrieve, I'd be very interested in hearing about it. Please contact me off-line. TIA, Greg Shirey Ben E. Keith Company wgshi...@benekeith.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Comparing - ISPF (3.12 and 3.13) with Comparex
We got rid of Comparex as well. File/AID has given us a way of pinpointing our compares so that our output reports a more focused. The formatted (using data maps or copybooks) output makes the report easy to use AND we found File/AID performed much better in terms of CPU because it did a lot more filtering before the compare process. We made some significant savings by making this decision. Regards. Simone. IT - Finance Division. On Sat, Feb 13, 2010 at 2:49 PM, Mike Shorkend mike.shork...@gmail.comwrote: This is what we did about a year a go - we got rid of Comparex and replaced it with File-AID(which we have anyway) The way we did it was by building our own wrapper for comparing files. That way, if we ever replace the compare engine again we don't have to change hundreds of jobs. This time it was very time consuming - going through all the jobs and replacing them with our wrapper. We did not find any Comparex feature that File-Aid could not do Mike On Fri, Feb 12, 2010 at 1:24 AM, Galambos, Robert robert.galam...@compuware.com wrote: OK, just adding my two cents. If you have File-AID MVS you already have a compare tool that does everything comperex does as well as others. And its part of the product. Sorry now back to your regular programming ;-) Robert Galambos CIPP/C CIPP/IT Compuware Senior Technical Specialist IBM Certified Database Associate IBM Certified DB2 9 for z/OS Database Administration Certified Information Privacy Professional/Canada Certified Information Privacy Professional/Information Technology robert.galam...@compuware.com Tel: +1 905 886 7000 Toll Free: +1 800 263 7189 Fax: +1 905 886 7023 Quebec: +1 877-281-1888 Le contenu de ce courriel s'adresse au destinataire seulement. Il contient de l'information pouvant être confidentielle. Vous ne devez ni le copier ni l'utiliser ni le divulguer à qui que ce soit à moins que vous soyez le destinataire ou une personne désignée autorisée. Si vous le receviez par erreur, veuillez nous aviser immédiatement et le détruire. The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Service in every product... Les renseignements contenus dans le présent message électronique sont confidentiels et concernent exclusivement le(s) destinataire(s) désigné(s). Il est strictement interdit de distribuer ou de copier ce message. Si vous avez reçu ce message par erreur, veuillez répondre par courriel à l'expéditeur et effacer ou détruire toutes les copies du présent message. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Greg Grimm Sent: February 9, 2010 12:20 PM To: IBM-MAIN@bama.ua.edu Subject: Comparing - ISPF (3.12 and 3.13) with Comparex Has anybody looked at replacing Comparex with the ISPF compare (SUPERC and SUPERCE - 3.12 and 3.13)? What are the specific product features for and against ISPF vs Comparex? Thanks in advance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mike Shorkend m...@shorkend.com www.shorkend.com Tel: +972524208743 Fax: +97239772196 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Entry point for a Mainframe?
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. ps2...@yahoo.com (Ed Gould) writes: In the mid 70's we had a T1 and we muxed it and IIRC we had 1 256K chunk and another chunk (sorry do not remember the speed) connected up to our 3745 and it worked really well (except a really strange bug which took us with the help of chance to figure out what the issue was). We were exercising it and kept it busy at least 20 out of 24 hours a day. I vaguely remember talking about the bug with IBM at the time (we were a small minority user of something like this at the time as IBM apparently only had a few people that seemed to know this part of NCP). Its not too surprising I guess that IBM really did not support a full T1 but if my memory (its iffy here) is correct it had something to do with the speed of the 3745 as to why IBM couldn't support it. SInce memory fades with time and I only remember small pieces we did seem to be on the bleeding edge at that time. re: http://www.garlic.com/~lynn/2010e.html#80 Entry point for a Mainframe? http://www.garlic.com/~lynn/2010e.html#81 Entry point for a Mainframe? 3705 in the 70s, 3725 in the 80s, 3745 later. this has (some?) 3745 withdrawn from marketing in sep2002 http://www.networking.ibm.com/nhd/webnav.nsf/pages/375:375prod.html 3745 wiki page http://en.wikipedia.org/wiki/IBM_3745 3745 wasn't announced until 1988 http://www-03.ibm.com/ibm/history/history/year_1988.html in mid-80s, Laguade had an experimental 3725 that was dedicated to running single T1. corporation did have 2701 in the 60s that supported T1 ... but the communication group in the 70s acquired increasingly narrow myopic focus on dumb terminals; they also leveraged corporate politics to keep other business units out of areas that thot even remotely touched on what they believed was their responsibility. this shows up, at least in the constant battles my wife had with the communication group when she was in POK responsible for loosely-coupled architecture ... and only temporary truces that she could use her own protocol for machine-to-machine communication within datacenter walls. some past posts mentioning her peer-coupled shared data architecture ... which except for IMS hot-standby, saw little uptake until sysplex. http://www.garlic.com/~lynn/submain.html#shareddata the narrow focus on dumb terminal became increasingly rigid in the 80s ... even tho early on real 3270s were being replaced with more capable ibm/pcs and terminal emulation http://www.garlic.com/~lynn/subnetwork.html#emulation 2701s were becoming increasingly long in the tooth during this period. in the mid-80s, federal systems division did come up with zirpel card for S/1 that supported T1 (for special gov. bids). however, for the most part, if other business units couldn't be kept out purely using the argument that only communication group could produce communication related products ... then there was always studies like the fat pipe argument that would be presented to corporate hdqtrs ... showing that customers didn't even want such products. it was also motivation for senior engineer from disk division getting presentation slippped into the internal world-wide communication group annual conference ... where the opening statement was that the communication group was going to be responsible for the demise of the disk division. I got HSDT involved with babybell that had done NCP emulation on series/1 ... and I was deep into trying to put it out as a corporate product (and really got involved in interesting politics ... this is scenario where the truth is really stranger than fiction). In any case, I gave a presentation on the work at fall '86, SNA architecture review board meeting in Raleigh ... quickly putting out a series/1 based version while quickly porting to RIOS chip (aka rs/6000). the 3725 pieces of the numbers came from official corporate HONE configurator (sales marketing use for selling to customers) ... part of the presentation to fall '86 SNA architecture review board meeting in Raleigh http://www.garlic.com/~lynn/99.html#67 System/1 ? part of spring '86 common presentation on pu4/pu5 support in series/1 http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?) -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Comparing - ISPF (3.12 and 3.13) with Comparex
On Thu, 11 Mar 2010 18:43:44 +, simone redstock sredst...@googlemail.com wrote: We got rid of Comparex as well. File/AID has given us a way of pinpointing our compares so that our output reports a more focused. The formatted (using data maps or copybooks) output makes the report easy to use AND we found File/AID performed much better in terms of CPU because it did a lot more filtering before the compare process. We made some significant savings by making this decision. Regards. Simone. IT - Finance Division. Simone, do you work for Compuware? I looked back in the archives and I see a few posts from you and they are all related to this subject. In those posts you've had negative comments about all of the other vendors with competitive products and some of your statements are almost like a sales pitch (i.e. given us a way of pinpointing our compares so that our output reports a more focused Don't let your management bully you just for the sake of cutting costs.) That coupled with the fact that you are posting from a personal email address but you including a company tag line that appears to me like it is there to give your posts credibility, but no company name is mentioned and there have never been any other IBM-MAIN contributions that I can find. There is a very good chance that I'm barking up the wrong tree here, and if I am, I sincerely apologize, but I couldn't help notice. You might just love the products (and there is nothing wrong with that). Vendors: Note that my comments have nothing to do with any of the products mentioned. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Comparing - ISPF (3.12 and 3.13) with Comparex
In a message dated 3/11/2010 2:07:35 P.M. Central Standard Time, mzel...@flash.net writes: That coupled with the fact that you are posting from a personal email address but you including a company tag line that appears to me like it is there to give your posts credibility, but no company name is mentioned and there have never been any other IBM-MAIN contributions that I can find. John Anderson fired up the isvcosts list several years ago. They do pretty good on replacements and comparisons. No vendors allowed! I liked BRIO(Hyperion) better than anything, but vendor was offering Crystal Reports for the majority of the conversion. Here's a link to ASU's data warehouse overview. _http://www.asu.edu/data_admin/data_warehouse-overview.html_ (http://www.asu.edu/data_admin/data_warehouse-overview.html) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: electronic resources and books for learning Assembler?
Jared Stofflett wrote: I'm a totally blind programmer who needs to learn mainframe assembly. All the books that appear to be available were written before electronic publishing became popular. What resources are available in electronic format to teach myself assembler on the mainframe? A search of the popular electronic book sites with a programming focus such as http://www.safaribooksonline.com came up dry and IBM Redbooks doesn’t appear to have any introductory assembler material. Thanks for any info. Interesting. So you have a mail client that reads emails out loud? Are you aware that the latest versions of Acrobat Reader have an option to speak? Under the View menu, option Read Out Loud lets you activate and deactivate the Read Out Loud facility. Not sure if it meets your needs. If it does, we can use our Remote Contact Training option to go through our Assembler curriculum. Do you have access to a mainframe for running the labs? Contact me off-list if you wish to explore this further. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * z/OS application programmer training + Instructor-led on-site classroom based classes + Course materials licensing + Remote contact training + Roadshows + Course development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA Easytrieve replacement
On Thu, 11 Mar 2010 18:26:44 +, simone redstock sredst...@googlemail.com wrote: Most mainframe shops own File/AID. This has both an online and batch element to it. File/AID batch is very powerful and we have replaced many of our Easytrieve jobs with it. It performs better (less CPU) and is far easier to maintain. even some of our junior team members are proficient in File/AID batch. Have a look into your tools portfolio. If you have File/AID then it's a no brainer. We have both File/AID and EZT. I have a hard time imagining how FileAid or SORT could replace much of our EZT - except for our moderately simple reporting jobs. That is not a knock against any of those products. There is one product (IBM Migration Utility) that claims to support EZT, meaning it can convert EZT to COBOL on the fly and you can continue to code using EZT syntax if you wish. YRMV. Alternative 4GL products and conventional languages (COBOL, ASM, C, etc) would be options as well. Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Multi-Level Aliases and System Software
I don't yet use MLA for system datasets, but I was planning on trying them soon. I am doing z/OS 1.11 with SMS managed ZFS for root and such. I don't have DFHSM active in the sandbox. I also do not share the master catalogs. I need DFHSM and DFDSS processing and was planning to use MLA to move OMVS.SERVICE into a shared usercatalog. Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA Easytrieve replacement
i guess it depends why you are wanting to replace CA-Easytrieve money? functionality? ease of use? support? at many shops at which I have pretented to work, I have used a product once called QUIKJOB - now called Advantage⼧ VISION:Report yes it is another CA product - but it is the most versatile report writer and data manipulator i have used (i mostly used it for data manipulation)( i have used off and on since 1984) there is also CA-EARL (i have not used since 1985 - may not still exist) CA-CULPRIT (i have continously since 1986) Chris Hoelscher IDMS/DB2 Database Architect Humana Inc 502-476-2538 choelsc...@humana.com you only need to test the programs that you want to work correctly The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
Re: Multi-Level Aliases and System Software
Dave Gibney has already mentioned the only justification that occurs to me: datasets sharing a HLQ have varied sharing requirements (e.g. some datasets are dedicated to an image and others are shared by multiple images). Once upon a time, there may have been an additional justification: to isolate release levels of a product and thereby simplify cleanup (of the old release) and implementation (i.e. switching the new release on by changing the UCAT association). SYMBOLICRELATE aliases may now be used to accomplish the same thing. I have occasionally noticed that, because it uses its own LOCATE mechanisms, ISPF 3.4 sometimes returns some weird results in MLA environments. Alan Starr -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Eells Sent: Wednesday, March 10, 2010 05:49 Subject: Multi-Level Aliases and System Software If you are using MLAs to manage system software data sets (z/OS, DB2, CICS, IMS, WAS, ISV products), please let me know. I don't know why anyone would need to do so but I'm willing to learn why it might be necessary. If you're using MLA for something else (application data, etc.), I don't need to know about it. Given a couple of fairly recent threads, it's probably a good idea to add, before anyone panics, that we do *not* intend to remove support for MLA as far as I know. Thanks! -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ACIF question - variable length input
Thank you very much. This answers my question. Basically, my problem was that I had an invoke data map command where the name of the data map itself was less than 8 characters. With fixed length format the record looked like this: 5A0010D3ABCA00D7F2C4E2D4E3F140404040404040404040... (with spaces (x40) padding to the end of the record) ACIF, as I guess one would expect, simply looks at the data following the 5A, gets the length (16) and looks only that far. Basically it ignores all of the spaces after the first one; with the first one being part of the 8-character resource name. Anyway, when I used variable length records I simply truncated all trailing spaces. And thus my problem. Now that I write the full 17 characters (5A followed by the 16 character invoke data map command) it works. Thanks again! Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 3/11/2010 at 9:32 AM, in message listserv%201003111032479011.2...@bama.ua.edu, Howard Turetzky howard.turet...@infoprint.com wrote: Peter is correct. Structured fields carry their own length. They can be carried in fixed-length fields (there is a bit in the structured field introducer that indicates the record is padded). This is inefficient for files that are fully-composed (ie., that are complete documents or objects containing only structured fields). In z/OS or VSE, a MO:DCA (AFP) variable-length file consists of RDW, x'5A' (usually--identifies structured fields to the spooler), 2-byte length (excludes the x'5A'), and the remainder of the record. ACIF checks the record length in the RDW against the structured field length (plus the x'5A' if present). If the padding flag is off (the normal case), then the record length must match as above or ACIF issues the APK114S message. Howard Turetzky Advanced Technical Support (and former ACIF lead developer) InfoPrint Solutions Company howard.turet...@infoprint.com On Wed, 10 Mar 2010 17:15:12 -0700, Frank Swarbrick frank.swarbr...@efirstbank.com wrote: So we have ACIF working if the input is a fixed length dataset. If we switch to a variable length dataset it works only if the x'5A' records are padded with spaces so that those records are the maximum LRECL for that file. For other lines it handles it fine if they are shorter than the maximum LRECL. z/OS and VSE both exhibit this behavior. Is this documented somewhere? Seems bizarre. If I use a VB file where the 5A records are not padded with spaces I get the following messages: APK114S DATA IN AN INPUT RECORD OR RESOURCE IS INVALID: RDW LENGTH DOES NOT AGREE WITH LENGTH IN STRUCTURED FIELD INTRODUCER. APK117S DATA IN AN INPUT RECORD OR RESOURCE IS INVALID: LENGTH INDICATED IN THE STRUCTURED FIELD INTRODUCER IS INCORRECT FOR IMM STRUCTURED FIELD. If my program writes to the output queue and I then use SDSF XDC to copy it to a (VBA) dataset it automatically keeps the 5A records space padded but all of the others are not. But if I write to the dataset directly I have to change my program to strip trailing spaces on all records except for the 5A records. Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for
Re: electronic resources and books for learning Assembler?
Paul Gilmartin wrote: On Thu, 11 Mar 2010 08:15:08 -0700, Steve Comstock wrote: Interesting. So you have a mail client that reads emails out loud? There are general purpose screen readers that render to either voice or Braille touchpads. The oldest of these work only with serial linemode data (VT- as opposed to 3270). All are thwarted by text embedded in a JPEG, etc. CAPTCHAs, anyone? Are you aware that the latest versions of Acrobat Reader have an option to speak? Under the View menu, option Read Out Loud lets you activate and deactivate the Read Out Loud facility. One must hope there's a keyboard shortcut to this facility. -- gil Yes indeedy. Shift+Cgtrl+Y turns on Read Out Loud then you can use Shift-Ctrl-V to read the current page Shift-Ctrl-B to read to the end of the document Shift-Ctrl-Y to turn off Read Out Loud -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * z/OS application programmer training + Instructor-led on-site classroom based classes + Course materials licensing + Remote contact training + Roadshows + Course development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Multi-Level Aliases and System Software
On Thu, 11 Mar 2010 13:50:12 -0800, Starr, Alan alan_st...@calpers.ca.gov wrote: Dave Gibney has already mentioned the only justification that occurs to me: datasets sharing a HLQ have varied sharing requirements (e.g. some datasets are dedicated to an image and others are shared by multiple images). Once upon a time, there may have been an additional justification: to isolate release levels of a product and thereby simplify cleanup (of the old release) and implementation (i.e. switching the new release on by changing the UCAT association). SYMBOLICRELATE aliases may now be used to accomplish the same thing. I have occasionally noticed that, because it uses its own LOCATE mechanisms, ISPF 3.4 sometimes returns some weird results in MLA environments. Alan Starr A former client of mine had all their system data sets (not application) under things like PROD.* and TEST.* (not including IBM sysres). They never wanted to go back and change JCL and standards. When MLA came along, they were able to split out the catalogs into multiple catalogs in order to help system performance (reduce catalog contention, response time, etc.). For example, PROD.CA1 in USERCATA, PROD.FDR in USERCATB etc. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Concatenating SORTIN short LRECL DSN's with DD * input?
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Frank Yaeger
Sent: Thursday, March 11, 2010 1:10 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Concatenating SORTIN short LRECL DSN's with DD * input?
Snipped
How about using TRAILER1 to add the additional records at the end of
the
output file:
//SORTIN DD DISP=SHR,DSN=TSOUSER.LRECL45.FILE1
// DD DISP=SHR,DSN=TSOUSER.LRECL45.FILE2
...
//SYSIN DD *
...
OUTFIL REMOVECC,
TRAILER1=('ADDITIONAL RECORD 1 DATA',/,
'ADDITIONAL RECORD 2 DATA')
Thanks for the idea Frank, but the data to be added at the end of SORTIN
needed to be sorted with the rest of the SORTIN data, because the key in
the additional data is not the highest key in the set.
I had to move forward with this little project so I just created a
one-record dataset with the same DCB attributes as the other SORTIN
files so I could get on with the job.
Thanks again for trying to help.
Peter
This message and any attachments are intended only for the use of the addressee
and
may contain information that is privileged and confidential. If the reader of
the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
UK GSE Large Systems Meetings Annual Conference -- Dates Call For Papers
IBM-Main, Apologies for the intrusion for what is most probably a series of events not relevant to a large number of the subscribers. It is my pleasure to announce the dates for the 2010 GSE Large Systems meetings. * 12th May 2010 - Location TBC, probably in the south * 8th Sept 2010 - Location TBC, probably IBM Warwick The annual conference will be once again at Whittlebury Hall on the 2nd 3rd Nov. Details for the conference can be found at www.gse.org.uk/tyc. The website will be updated as we progress towards November, please check regularly for the latest news. I know there are lots of vendors on the list and anyone wishing to participate as a sponsor or exhibitor can download a PDF with details at: http://www.gse.org.uk/tyc/vl/Letter%20to%20Vendors%202010.pdf I am also looking for a list of topics that you would like to see covered at the LSG meetings and annual conference. If you have any suggestions please drop me a note and I will see if we can find a willing presenter. Then the most difficult part of this job...Anyone willing to present for an hour on a suitable topic? It¹s not that bad, honestly and there a lots of people willing to offer hints tips if you have never done it before. Looking forward to the rush of emails offering suggestions for topics and willing presenters! Hopefully see you all at a meeting in 2010. Regards Mark Mark Wilson Work: GSE: Technical Director Chairman Large Systems Group RSM Partners : www.lsx.gse.org.uk Greenhill Industrial Estate Birmingham Road GSE UK Conference Manager Kidderminster : www.gse.org.uk/tyc DY10 2RN +: ma...@rsmpartners.com +: mark.wil...@gse.org.uk : www.rsmpartners.com : www.gse.org.uk È: +44 (0) 7768 617006 ( +44 (0) 870 050 1004 -- End of Forwarded Message -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Comparing - ISPF (3.12 and 3.13) with Comparex
1) there is NO one with the last name of redstock in the compuware directory. 2) so it seems that someone who likes a product, is set up for questioning because of such 3) this list is for an open discussion. Good or bad. I normally refrain from posting unless there is a question pertaining to some compuware tool. BUT questioning someone just because they like ANY product works, no matter who makes it.. 4) and there are a number of people who use non business emails, as to avoid being called at work by a vendor. Absolutely nothing wrong with that. 5) I suggest that everyone here make up their own minds about who an poster is etc. Robert Galambos CIPP/C CIPP/IT Compuware Senior Technical Specialist IBM Certified Database Associate IBM Certified DB2 9 for z/OS Database Administration Certified Information Privacy Professional/Canada Certified Information Privacy Professional/Information Technology robert.galam...@compuware.com Tel: +1 905 886 7000 Toll Free: +1 800 263 7189 Fax: +1 905 886 7023 Quebec: +1 877-281-1888 Le contenu de ce courriel s'adresse au destinataire seulement. Il contient de l'information pouvant être confidentielle. Vous ne devez ni le copier ni l'utiliser ni le divulguer à qui que ce soit à moins que vous soyez le destinataire ou une personne désignée autorisée. Si vous le receviez par erreur, veuillez nous aviser immédiatement et le détruire. The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Service in every product... Les renseignements contenus dans le présent message électronique sont confidentiels et concernent exclusivement le(s) destinataire(s) désigné(s). Il est strictement interdit de distribuer ou de copier ce message. Si vous avez reçu ce message par erreur, veuillez répondre par courriel à l'expéditeur et effacer ou détruire toutes les copies du présent message. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: March 11, 2010 3:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Comparing - ISPF (3.12 and 3.13) with Comparex Simone, do you work for Compuware? I looked back in the archives and I see a few posts from you and they are all related to this subject. In those posts you've had negative comments about all of the other vendors with competitive products and some of your statements are almost like a sales pitch (i.e. given us a way of pinpointing our compares so that our output reports a more focused Don't let your management bully you just for the sake of cutting costs.) That coupled with the fact that you are posting from a personal email address but you including a company tag line that appears to me like it is there to give your posts credibility, but no company name is mentioned and there have never been any other IBM-MAIN contributions that I can find. There is a very good chance that I'm barking up the wrong tree here, and if I am, I sincerely apologize, but I couldn't help notice. You might just love the products (and there is nothing wrong with that). Vendors: Note that my comments have nothing to do with any of the products mentioned. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Comparing - ISPF (3.12 and 3.13) with Comparex
John Anderson runs a listserv that does not accept ISV input true. BUT john Anderson works for IBM. Sounds a little self serving as IBM is its itself a Software vendor. If you want to question items, that maybe something you may want to also consider Robert Galambos CIPP/C CIPP/IT Compuware Senior Technical Specialist IBM Certified Database Associate IBM Certified DB2 9 for z/OS Database Administration Certified Information Privacy Professional/Canada Certified Information Privacy Professional/Information Technology robert.galam...@compuware.com Tel: +1 905 886 7000 Toll Free: +1 800 263 7189 Fax: +1 905 886 7023 Quebec: +1 877-281-1888 Le contenu de ce courriel s'adresse au destinataire seulement. Il contient de l'information pouvant être confidentielle. Vous ne devez ni le copier ni l'utiliser ni le divulguer à qui que ce soit à moins que vous soyez le destinataire ou une personne désignée autorisée. Si vous le receviez par erreur, veuillez nous aviser immédiatement et le détruire. The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Service in every product... Les renseignements contenus dans le présent message électronique sont confidentiels et concernent exclusivement le(s) destinataire(s) désigné(s). Il est strictement interdit de distribuer ou de copier ce message. Si vous avez reçu ce message par erreur, veuillez répondre par courriel à l'expéditeur et effacer ou détruire toutes les copies du présent message. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ed Finnell Sent: March 11, 2010 3:30 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Comparing - ISPF (3.12 and 3.13) with Comparex In a message dated 3/11/2010 2:07:35 P.M. Central Standard Time, mzel...@flash.net writes: That coupled with the fact that you are posting from a personal email address but you including a company tag line that appears to me like it is there to give your posts credibility, but no company name is mentioned and there have never been any other IBM-MAIN contributions that I can find. John Anderson fired up the isvcosts list several years ago. They do pretty good on replacements and comparisons. No vendors allowed! I liked BRIO(Hyperion) better than anything, but vendor was offering Crystal Reports for the majority of the conversion. Here's a link to ASU's data warehouse overview. _http://www.asu.edu/data_admin/data_warehouse-overview.html_ (http://www.asu.edu/data_admin/data_warehouse-overview.html) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA Easytrieve replacement
Most mainframe shops own File/AID??? I didn't know that, but I do know mine does not. As much as our Compuware reps (who I like and respect) would like to have us replace Easytrieve with File/Aid, the programmers here who have worked with both report that it is *not* a no-brainer, for many of the reasons Paul Peplinski noted in another post. As the OP of this thread, I'm surprised to see it awaken after a couple of weeks of inactivity, but I'll take this opportunity to thank those who have contacted me offline to share their experiences. It has been most helpful. Greg Shirey Ben E. Keith co. On Thu, 11 Mar 2010 18:26:44 +, simone redstock wrote: Most mainframe shops own File/AID. This has both an online and batch element to it. File/AID batch is very powerful and we have replaced many of our Easytrieve jobs with it. It performs better (less CPU) and is far easier to maintain. even some of our junior team members are proficient in File/AID batch. Have a look into your tools portfolio. If you have File/AID then it's a no brainer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Comparing - ISPF (3.12 and 3.13) with Comparex
John Anderson runs a listserv that does not accept ISV input true. BUT john Anderson works for IBM. Sounds a little self serving as IBM is its itself a Software vendor. It's not as bad as you think, actually. IBM employees are not allowed to post, either. At least that was the case when I worked there. BUT, we were allowed to see expurgated digests (no company/poster names). And, you had to use company e-mail addresses - no private ones. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IRXANCHR - Number of environments
We have been running with 400 specified since sometime back in '03 with no problems until yesterday. We are a GDPS and SA/390 shop so there can be a lot of autotasks running during some configurations changes. Yesterday we got message CNM416I REXX INTERPRETER ENVIRONMENT INITIALIZATION FAILED FOR TASK AUTBAT26, RETURN CODE = 20, REASON CODE = 24 during a reconfig we were running that caused some minor problems for a while. IBM has recommended that we up IRXANCHR to avoid this in the future. One comment was It is not uncommon for customers to define 2000 or 3000 rexx environments on the system, and this serves not only netview/sa/gdps but other applications that use rexx. Q1: Is anyone out there running IRXANCHR in that range? Q2: If the default IRXANCHR is that high, is there any significant resource (i.e, storage, etc.) being wasted on the system as a whole or per address space? Q3: Does anyone run a default IRXANCHR with one value and a customized IRXANCHR with a higher value that is STEPLIB'd to GDPS, SA/390, NetView tasks? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
AUTO: Lionel Dyck is out of the office (returning 03/15/2010)
I am out of the office until 03/15/2010. I am out of the office. Call my cell if this is an emergency. Note: This is an automated response to your message Re: Multi-Level Aliases and System Software sent on 3/11/10 14:50:12. This is the only notification you will receive while this person is away. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SoftCopy Librarian
All, I installed SoftCopy Library 4.4 on Windows 7 Ultimate (64-bit). I received no errors during the install process. I am using Java 1.6.0 Modification 18 Build 07. I defined the locations of my softcopy directories, and then rebuilt the catalog. I then checked the Internet Source repository for any new publications. Everything worked perfectly. No errors. An excellent job on IBM's part. John P. Baker -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Test
Test. Please ignore. New email address. John P. Baker Chief Software Architect HFD Technologies -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Comparing - ISPF (3.12 and 3.13) with Comparex
yet ISV are not allowed to see anything including expurgated digests. enough said Le contenu de ce courriel s'adresse au destinataire seulement. Il contient de l'information pouvant être confidentielle. Vous ne devez ni le copier ni l'utiliser ni le divulguer à qui que ce soit à moins que vous soyez le destinataire ou une personne désignée autorisée. Si vous le receviez par erreur, veuillez nous aviser immédiatement et le détruire. The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. From: IBM Mainframe Discussion List on behalf of Ted MacNEIL Sent: Thu 3/11/2010 6:03 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Comparing - ISPF (3.12 and 3.13) with Comparex John Anderson runs a listserv that does not accept ISV input true. BUT john Anderson works for IBM. Sounds a little self serving as IBM is its itself a Software vendor. It's not as bad as you think, actually. IBM employees are not allowed to post, either. At least that was the case when I worked there. BUT, we were allowed to see expurgated digests (no company/poster names). And, you had to use company e-mail addresses - no private ones. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Comparing - ISPF (3.12 and 3.13) with Comparex
yet ISV are not allowed to see anything including expurgated digests. enough said I'm not coming to anybody's defence, but nobody else is running one. It may be 'wrong', but it's not copyrighted. Anybody else could run a similar forum, but they don't. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ACIF question - variable length input
Basically, my problem was that I had an invoke data map command where the name of the data map itself was less than 8 characters. With fixed length format the record looked like this: 5A0010D3ABCA00D7F2C4E2D4E3F140404040404040404040... (with spaces (x40) padding to the end of the record) Note that the case of your fixed length record will fail should that file ever be sent to and processed on a platform that does not have a concept of logical record length that is tied to a file. Then, the structured field length is the only means that an AFP data stream interpreter has left to find out where the next logical record starts. In the above case, the next record after the IDM record would start at offset 17 from the X'5a', which is a blank (X'40') and this most probably yields an error. -- Peter Hunkeler CREDIT SUISSE AG -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
