Re: IBM Press Release: New Mainframe Customer in Korea
I would never automatically assume that consolidation equals Linux on System z. Consolidation to z/OS is also quite popular. Or, said another way, if you're a new z/OS customer then by definition (and automatically) you're probably enjoying huge consolidation benefits. We sometimes forget that and/or take it for granted. I don't know exactly how many frames BC Card is installing, but I can make a safe bet: to support the same (or more) workloads it'll be far fewer machines. This is z/OS we're talking about here, and you just don't need many machines. A couple (in Parallel Sysplex) at the primary site plus one at the DR site is a very nice installation indeed -- and can grow to be enormous (in workload terms) without increasing the machine count. For some background reading, here's an article I wrote entitled "How Many Mainframes Do You Need?" http://mainframe.typepad.com/blog/2009/03/how-many-mainframes-do-you-need.html - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific 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: Assembler program calling a 'C' program with mixed case long names
You can't use the pre-linker with GOFF. If I were you I would ditch the pre-linker. It's functionally stabalized and the binder does everything you need and more. Only use the pre-linker if you want to use load modules in a PDS. Steve Austin wrote: Thanks for all your responses. I am now fighting with the pre-linker; it does not pick up the long mixed case names I specified using alias statements. Steve -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Binyamin Dissen Sent: 23 December 2009 18:45 To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler program calling a 'C' program with mixed case long names On Wed, 23 Dec 2009 15:55:12 - Steve Austin wrote: :>Is it possible to persuade the assembler to create mixed case ESD names? :>The GOFF option allows long names, but the ESD entries are upper case. Look at the assembler ALIAS statement. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 internal virus protection system. . - This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 internal virus protection 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
Re: JES SPOOL "quota" by user?
I would print it for him and deliver the hardcopy in a Santa outfit... > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Brian Westerman > Sent: Thursday, December 24, 2009 12:54 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] JES SPOOL "quota" by user? > > One of the things that SyzSpool was written to handle is situation like > this. SyzSpool allows you to manage the spool and it's very inexpensive. > You can set up the rules to handle "individuals" like this and have their > data be maintained (off the spool) to any age that you want it to be kept, > since the data is off the spool volume(s) and compressed, (or on tape if it > has reached the migration age), the user can't tie things up. > > On the user's side, they have complete access to their data via ISPF or the > Web interface. > > Brian > > -- > 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: Movin' on Up!
>>Ugly smog, but beautiful baech. Do you surf ? >The smog is nearly gone in L.A. When I first moved here, Stage I Health Alerts issued by AQMD were all too common I haven't been to LA since the late 1960's. The smog was miserable then, mostly due to the cars and the still air in the basin. - 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: PSF z/OS from VSE
Thanks Howard. Wanted to make sure I wasn't going the "long way" unnecessarily. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 12/23/2009 at 11:25 PM, in message , Howard Turetzky wrote: > You are correct in that z/OS has no equivalent to stored attributes. The all > must appear on > the // OUTPUT statement. > > See > http://www-01.ibm.com/support/docview.wss? > rs=95&context=SRNPYM&dc=D400&q1=psd1*&q2=vseres&uid=psd1P4000210&loc=en_US&cs= > utf-8&lang=en > for my vseres tool that will decode the FNO module into an // OUTPUT > statement. > > -- > 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 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
Re: INCREASING SIZE OF VIR - VTOC INDEX RECORD
>I want some of what they're smokin'.
That'd get you into trouble in most of the Western World. (8-{]}
>It's either full, or it's not and there
is no performance difference that I ever heard of.
Same here, and I've been using them since they first came out.
>Actually, if you could measure it, perhaps a (grossly) over-allocated VTOCIX
>would probably perform worse.
I doubt it, since it is indexed -- one of the reasons it performs better than
any old VTOC.
>Are you sure it wasn't a disabled VTOCIX?
Probably the real problem.
-
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: INCREASING SIZE OF VIR - VTOC INDEX RECORD
To confirm the VTOC was inabled. This was verified via ISMF. --- On Fri, 25/12/09, Mark Zelden wrote: From: Mark Zelden Subject: Re: INCREASING SIZE OF VIR - VTOC INDEX RECORD To: IBM-MAIN@bama.ua.edu Received: Friday, 25 December, 2009, 2:49 AM I want some of what they're smokin'. It's either full, or it's not and there is no performance difference that I ever heard of. Actually, if you could measure it, perhaps a (grossly) over-allocated VTOCIX would probably perform worse. Are you sure it wasn't a disabled VTOCIX? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html On Thu, 24 Dec 2009 05:40:17 -0800, John Dawes wrote: >Barry, > >Our Capacity performance group said that the slow response time for some volumes was caused by the small VTOCIX. The suggestion was made to increase it. > >--- On Wed, 23/12/09, Schwarz, Barry A wrote: > > >From: Schwarz, Barry A >Subject: Re: INCREASING SIZE OF VIR - VTOC INDEX RECORD >To: IBM-MAIN@bama.ua.edu >Received: Wednesday, 23 December, 2009, 6:41 AM > > >I assume you meant the size of the VTOCIX dataset and not the size of the VIR in the dataset. > >The job matches what I use (except I don't include the VTOCIX DSN in the first step). > >But what makes you think the VTOCIX is undersized? The CVAFDSM macro will tell you how many VIRs are still available in the dataset. > >-Original Message- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Dawes >Sent: Tuesday, December 22, 2009 7:04 AM >To: IBM-MAIN@bama.ua.edu >Subject: INCREASING SIZE OF VIR - VTOC INDEX RECORD > >Good Evening To All, > >We have noticed that some of the VIRs on several volumes are very small. We would like to increase the size. I am not sure if I am on the right track this is why I need your help. > >The VIR exsists on the volume and in order to increase the size I will need to purge it and reallocate it. Below are the 2 jobs I would like to use. Would they work? Is there another way of going about it? I would welcome your suggestions. > >Job to delete the VTOCIX > >//STEP1 EXEC PGM=ICKDSF,REGION=3M >//MYVOL DD UNIT=(3390,,DEFER),VOL=SER=PROD21, >// DSN=SYS1.VTOCIX.PROD21,DISP=SHR >//SYSIN DD * >//SYSPRINT DD SYSOUT=* >//SYSIN DD * >BUILDIX DDNAME(MYVOL) OSVTOC PURGE >/* >Job to build the VTOCIX > >/* >//STEP01 EXEC PGM=ICKDSF,REGION=4M,PARM='NOREPLYU' >//PROD21 DD DSN=SYS1.VTOCIX.PROD21,UNIT=SYSALLDA, >// VOL=SER=PROD21,DISP=NEW,SPACE=(CYL,(2)) >//SYSPRINT DD SYSOUT=* >//SYSIN DD * > BUILDIX IXVTOC,DDNAME(PROD21) >/* >// > >-- >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 > __ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ > >-- >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 __ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ -- 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: INCREASING SIZE OF VIR - VTOC INDEX RECORD
Scott, Thanks for the tip. I will pose the question. --- On Fri, 25/12/09, Scott Rowe wrote: From: Scott Rowe Subject: Re: INCREASING SIZE OF VIR - VTOC INDEX RECORD To: IBM-MAIN@bama.ua.edu Received: Friday, 25 December, 2009, 1:55 AM John, I have never heard of such a thing, and I think they are confused. As long as the VTOCIX is not full (or nearly so), I see no reason to expand it. I would ask them to show you some reference that backs up their performance claim. >>> John Dawes 12/24/2009 8:40 AM >>> Barry, Our Capacity performance group said that the slow response time for some volumes was caused by the small VTOCIX. The suggestion was made to increase it. 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 __ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ -- 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: Movin' on Up!
Thanks to everyone for the well-wishes. Some specific answers to specific questions: George Fogg wrote: http://www.phoenixsoftware.com/newlocation.htm Nice digs, you get that nice corner office? My boss gets the corner. Mine is nice though... Gabriel Tully wrote: Those beams on your raised floor seem odd. Were they placed like that for aesthetics or are they actually structural? They seem to take up some unnecessary real estate. Elardus Engelbrecht wrote: ... I'm little worried about that green diagonal beams in that computer room, you'll need a hard hat to avoid headaches... ;-D Those beams are structural. I assume you're supposed to hide them inside a wall. My boss wanted to put the computer room in the exact center of the building. I'm not sure why those diagonal beams did not cause him to rethink that plan. There might have been other factors that forced him into the present layout. I agree they are a hazard--and a PITA. (I kept having to avoid them when doing some wiring yesterday.) Someone is supposed to install some kind of tape rack and/or guard rails to make them more useful and prevent people running into them. I don't think hitting your head on a beam in the computer room is what they had in mind when the phrase "lights out computer operation" was coined. ;) Mark Zelden wrote: Does your current equipment reside at the old location and is it moving, or is it already in the new location? Or is there some "duplicate" equipment staged at the new location for the move like the "big boys" do? We did the move yesterday. We don't have duplicate equipment. The z10, DASD, tape and every thing else were powered down in the old space starting around 2 PM on Tuesday. They were then packed up, moved, and placed in the new computer room. That day ended around 11:30 PM. 8 AM Wednesday we started pulling cables in the new space. By 1 PM we started powering everything up. I got out of there around 7 PM and finished some IPLs and other things from home. I declared us fully operational at 9 PM. Since about a week prior to the move, our web and email has been hosted in our Tulsa, OK office. Chris Craddock wrote: Cool. How's the noise level there? I assume that question arises from our close proximity to LAX. Planes fly in/out of LAX in one direction: West. The (noisier) take-off flight path is over the ocean. Our old location was rented space on the 8th floor in the building at 5200 W. Century Blvd at La Cienega Blvd. Prior to that we rented at 9841 Airport Blvd at Century Blvd and prior to that at 5933 W. Century Blvd. All three of those locations were directly in the (quieter) landing flight path along Century Blvd just a couple/few blocks East of the airport. Even so, we never heard much unless a plane got really close. All the buildings in the area have excellent soundproofing. It was kinda' neat to be able to watch planes land from the window of my office... I'll miss that. Our new space is South of LAX and no longer in any flight path. During yesterday's move, I heard no airport noise at all. Schwarz, Barry A wrote: Was the absence of chairs in the conference room deliberate to keep meetings from running to long? (Since most executives seem to prefer chairs with wheels, I expect the obvious adjustment.) I am surprised there is no sign or other identification. Most companies seem to want there name in lights. There are chairs in the conference room now. They do have wheels. :) Our trademarked "P" logo is proudly displayed behind the receptionist's desk. I'm not sure if we plan to put signage on the outside of the building. I certainly hope so. We had it on the old building, and we were only renting there... Ganesh Rao wrote: Ed, isn't that close to where Candle used to have one of their office in early 2001? I remember Candle had an El Segundo address for a while. I have no idea where that was. Our new building is brand new construction in an area called the Edge at Campus El Segundo http://www.edgeatcampuselsegundo.com/ Many satellite and aerial views from the popular mapping services still show a big, empty plot of land. Some of them don't even show Parkview Drive North yet... I'll wait a while before I upgrade the GPS maps in my car. :) R.S. wrote: BTW: I was some time ago in the neighbourhood. Ugly smog, but beautiful baech. Do you surf ? The smog is nearly gone in L.A. When I first moved here, Stage I Health Alerts issued by AQMD were all too common: 84 in 1983, 97 in 1984, 83 in 1985, and so on. We've had only one in the past 11 years. http://www.aqmd.gov/smog/o3trend.html The beaches are still nice. I've never been much of a surfer. My other gig was playing rock music... -- Edward E Jaffe Chief Technology Officer Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.co
Re: INCREASING SIZE OF VIR - VTOC INDEX RECORD
On Thu, 24 Dec 2009 08:58:56 -0700, Lester, Bob wrote: >Hi Mark, > >Indeed it does. We have a report distribution system on our >mainframe. It creates thousands of very small ESDS files. We were >constantly filling up VTOC, VTOCIX, and extending like crazy on the >VVDS. > >We ended up using very large values for these volumes. > > INIT UNIT(465E) NOCHECK PURGE VERIFY(HT465E) VOLID(CLDH60) - > VTOC(0,1,1200) INDEX(81,1,180) STORAGEGROUP > >DEFINE CLUSTER( - > NAME(SYS1.VVDS.VCLDH60) - > VOLUMES(CLDH60) - > NONINDEXED - > CYLINDERS(30 5)) > >This solves the issue, but performance isn't great. > >Just FWIW. > >BobL > It it an apples to apples comparison? In other words, if there are only 100 files on the volume with a smaller VTOCIX vs a 180 track VTOCIX (which isn't that large), how much slower is it to locate a specific data set? Or if you increase the VTOCIX from 180 tracks to 300 tracks can you notice or measure the difference? I'm sure with thousands of ESDS files the performance isn't great, but I don't think it's "due to a large VTOCIX". You also added some other parameters into the equation here since you have a very large VVDS and are talking about VSAM - the Very Slow Access Method. :-) But as a disclaimer, I will state that I have never done any of my own studies on this nor looked into it (any CMG folks out there who know of specific studies?). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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 MSM
On Thu, 24 Dec 2009 10:44:15 -0500, Mark Jacobs
wrote:
>>
>
>I don't have any philosophical objections making day to day work easier,
>in fact that's one of my main goals in my professional career. The
>problem with all these gee-whiz tools is that they remove/eliminate the
>need for understanding the way things work under the covers. As system
>programmers we have to know the nuts and bolts of the environments we
>support else when things break (and they always will) they can't be
>fixed by using your own personal experience and knowledge.
>
>Look at the personal computer environment as an example. If an automated
>install process fails at the best it will automatically back itself out,
>at the worst your system is dead. Do we want our environments to even
>more dependent on vendors fixing all our problems?
>
>These tools are another attempt to dumb down the system programmer work
>force and allow management to say to themselves why do I need an
>expensive system programmer when I can get a button pusher who can click
>an icon on a screen for far less money.
>
Mark,
I sort of agree, but I don't think it applies in this specific case. There can
and will be problems with installs related to this software, and it will still
take an experienced or knowledgeable sysprog to look at the details (output)
generated to figure out what is wrong. I don't see that as being any different
than any other problem "I" end up looking at to resolve because someone
with less experience or knowledge couldn't figure it out. This just makes
it easier for the inexperienced sysprog *and* the experienced one. From all
the "playing" I have been doing the last couple of weeks, I do understand
what is going on under the covers, so that would enable me ("the senior
sysprog") to help a junior sysprog or someone else.
"We" (as a sysprog community) already rely heavily on vendors to help us
to fix problems with their software. Of course to varying degrees depending
on the complexity of the software and the problem, but I'm sure there isn't
a single sysprog out there who hasn't contacted a vendor at one point or
another for help on a problem with every product they run / use / support.
How many MVS sysprogs out there understand Datacom enough to fix
Datacom problems with CA-11 or JOBTRAC or IDMS issues with Dispatch
(BTW, I've supported Dispatch at various shop / clients for 20 years and
when there was an "IDMS" issue I needed to contact CA about, they've
been able to provide timely assistance).
And before you trash CA for making things "complicated", by trying
to enhance their software to run 24 x 7, our "experienced" z/OS
WebSphere sysprogs (been using it here since component broker) end up
on the phone with IBM or opening PMRs for assistance for problems / issues
practically on a daily basis (at least it seems that way). Operating systems
and software today are more complicated than they used to be - at least
under the covers. And the more that there is under the covers, the more
an expert / vendor will be needed to help when things go wrong. I don't
see that changing.
Be open to change. Adapt or become extinct. Unfortunately, it's probably
too late for the mainframe already, but at least there are some out there
who believe it isn't and are trying to change it regardless. I for one
really hope they succeed.
Cheers,
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark.zel...@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: INCREASING SIZE OF VIR - VTOC INDEX RECORD
Hi Mark, Indeed it does. We have a report distribution system on our mainframe. It creates thousands of very small ESDS files. We were constantly filling up VTOC, VTOCIX, and extending like crazy on the VVDS. We ended up using very large values for these volumes. INIT UNIT(465E) NOCHECK PURGE VERIFY(HT465E) VOLID(CLDH60) - VTOC(0,1,1200) INDEX(81,1,180) STORAGEGROUP DEFINE CLUSTER( - NAME(SYS1.VVDS.VCLDH60) - VOLUMES(CLDH60) - NONINDEXED - CYLINDERS(30 5)) This solves the issue, but performance isn't great. Just FWIW. BobL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Thursday, December 24, 2009 8:49 AM To: IBM-MAIN@bama.ua.edu Subject: Re: INCREASING SIZE OF VIR - VTOC INDEX RECORD I want some of what they're smokin'.It's either full, or it's not and there is no performance difference that I ever heard of. Actually, if you could measure it, perhaps a (grossly) over-allocated VTOCIX would probably perform worse. -- This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. == -- 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 MSM
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Jacobs > Sent: Thursday, December 24, 2009 9:44 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: CA MSM > > > I don't have any philosophical objections making day to day > work easier, > in fact that's one of my main goals in my professional career. The > problem with all these gee-whiz tools is that they > remove/eliminate the > need for understanding the way things work under the covers. > As system > programmers we have to know the nuts and bolts of the environments we > support else when things break (and they always will) they can't be > fixed by using your own personal experience and knowledge. > > Look at the personal computer environment as an example. If > an automated > install process fails at the best it will automatically back > itself out, > at the worst your system is dead. Do we want our environments to even > more dependent on vendors fixing all our problems? > > These tools are another attempt to dumb down the system > programmer work > force and allow management to say to themselves why do I need an > expensive system programmer when I can get a button pusher > who can click > an icon on a screen for far less money. > > > > -- > Mark Jacobs The entire point of IT and automation is to remove the need for non-vendor companies to have any technical expertise. I.e. to "dumb down" the workforce. This is a plus to companies, in general, as it allows them to hire cheaper labor who become productive in a shorter period of time. Again, this is a plus because it means that people are easily replaceable and interchangeable. How many jobs have computers eliminated? How many accountants does a company need now as opposed to 30 years ago? How many file clerks? Eventually, there will be no need for any non-management people. That is "company nirvana". Not that I like it. -- 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: INCREASING SIZE OF VIR - VTOC INDEX RECORD
I want some of what they're smokin'.It's either full, or it's not and there is no performance difference that I ever heard of. Actually, if you could measure it, perhaps a (grossly) over-allocated VTOCIX would probably perform worse. Are you sure it wasn't a disabled VTOCIX? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html On Thu, 24 Dec 2009 05:40:17 -0800, John Dawes wrote: >Barry, > >Our Capacity performance group said that the slow response time for some volumes was caused by the small VTOCIX. The suggestion was made to increase it. > >--- On Wed, 23/12/09, Schwarz, Barry A wrote: > > >From: Schwarz, Barry A >Subject: Re: INCREASING SIZE OF VIR - VTOC INDEX RECORD >To: IBM-MAIN@bama.ua.edu >Received: Wednesday, 23 December, 2009, 6:41 AM > > >I assume you meant the size of the VTOCIX dataset and not the size of the VIR in the dataset. > >The job matches what I use (except I don't include the VTOCIX DSN in the first step). > >But what makes you think the VTOCIX is undersized? The CVAFDSM macro will tell you how many VIRs are still available in the dataset. > >-Original Message- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Dawes >Sent: Tuesday, December 22, 2009 7:04 AM >To: IBM-MAIN@bama.ua.edu >Subject: INCREASING SIZE OF VIR - VTOC INDEX RECORD > >Good Evening To All, > >We have noticed that some of the VIRs on several volumes are very small. We would like to increase the size. I am not sure if I am on the right track this is why I need your help. > >The VIR exsists on the volume and in order to increase the size I will need to purge it and reallocate it. Below are the 2 jobs I would like to use. Would they work? Is there another way of going about it? I would welcome your suggestions. > >Job to delete the VTOCIX > >//STEP1 EXEC PGM=ICKDSF,REGION=3M >//MYVOL DD UNIT=(3390,,DEFER),VOL=SER=PROD21, >// DSN=SYS1.VTOCIX.PROD21,DISP=SHR >//SYSIN DD * >//SYSPRINT DD SYSOUT=* >//SYSIN DD * >BUILDIX DDNAME(MYVOL) OSVTOC PURGE >/* >Job to build the VTOCIX > >/* >//STEP01 EXEC PGM=ICKDSF,REGION=4M,PARM='NOREPLYU' >//PROD21 DD DSN=SYS1.VTOCIX.PROD21,UNIT=SYSALLDA, >// VOL=SER=PROD21,DISP=NEW,SPACE=(CYL,(2)) >//SYSPRINT DD SYSOUT=* >//SYSIN DD * > BUILDIX IXVTOC,DDNAME(PROD21) >/* >// > >-- >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 > __ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ > >-- >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 MSM
On 12/24/09 10:24, Mark Zelden wrote: Another kudos to CA from me... (Note: I have been playing with MSM a lot on a sandbox LPAR / sysplex and plan on "thowing away" what I am doing now and re-installing in a different LPAR early next year.) MSM is s cool. This morning I received notice that MIM 11.7 SP1 was GA and available. With a few mouse clicks I downloaded it, deleted SP0 (which I had installed for the "team demo" I did last week but wasn't in use) and installed SP1 all before I finished my cup of coffee. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html I don't have any philosophical objections making day to day work easier, in fact that's one of my main goals in my professional career. The problem with all these gee-whiz tools is that they remove/eliminate the need for understanding the way things work under the covers. As system programmers we have to know the nuts and bolts of the environments we support else when things break (and they always will) they can't be fixed by using your own personal experience and knowledge. Look at the personal computer environment as an example. If an automated install process fails at the best it will automatically back itself out, at the worst your system is dead. Do we want our environments to even more dependent on vendors fixing all our problems? These tools are another attempt to dumb down the system programmer work force and allow management to say to themselves why do I need an expensive system programmer when I can get a button pusher who can click an icon on a screen for far less money. -- Mark Jacobs Time Customer Service Tampa, FL To one large turkey add one gallon of vermouth and a demijohn of Angostura bitters. Shake. -- F. Scott Fitzgerald, recipe for turkey cocktail. -- 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: Assembler program calling a 'C' program with mixed case long names
Steve Austin wrote: Thanks for all your responses. I am now fighting with the pre-linker; it does not pick up the long mixed case names I specified using alias statements. Steve Steve, When you say "pick up" - what do you mean? And, which pre-linker is this? - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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: Assembler program calling a 'C' program with mixed case long names
Hi Steve, Use the ALIAS command to get precisely the letter's you'd like in the ESD name. For example: NAME ALIAS C'name' NAME CSECT END creates a csect that has the letters "name" in the object deck. - Dave Rivers - Steve Austin wrote: Hello, Is it possible to persuade the assembler to create mixed case ESD names? The GOFF option allows long names, but the ESD entries are upper case. Thanks Steve - This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 internal virus protection 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 -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.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: CA MSM
Another kudos to CA from me... (Note: I have been playing with MSM a lot on a sandbox LPAR / sysplex and plan on "thowing away" what I am doing now and re-installing in a different LPAR early next year.) MSM is s cool. This morning I received notice that MIM 11.7 SP1 was GA and available. With a few mouse clicks I downloaded it, deleted SP0 (which I had installed for the "team demo" I did last week but wasn't in use) and installed SP1 all before I finished my cup of coffee. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html On Thu, 10 Dec 2009 03:37:48 +, Norman Hollander wrote: >Just a correction to a badly typed reply to this thread earlier this week; > >CA Mainframe Software Manager does NOT need any additional servers; >it runs completely on z/OS. Thanks for your good words. I do work for >CA (but you all know that). > >znor...@ca.com >-Original Message- >From: Mark Zelden [mailto:mark.zel...@zurichna.com] >Sent: Wednesday, December 9, 2009 04:39 PM >To: IBM-MAIN@bama.ua.edu >Subject: Re: CA MSM > >>>You are entitled to your opinion and you don't have to use it. I assume it >>>will always remain optional to use it or not. I see it as being a big time >>>saver for me and my fellow workers that know how to download files, >>>allocate data sets, and run SMP/E. So it is a good thing for experienced >>>sysprogs as well as inexperienced ones. I can install a HIPER PTF into my >>>maintenance environment with the click of a mouse in a minute instead >>>of having to go out to CA's web site, download the file to my workstation, >>>upload to z/OS, then run SMP/E RECEIVE and APPLY. >>> >>I'm missing something. If you have suitable Internet connectivity, >>can't you run RECEIVE FROMNETWORK or RECEIVE ORDER without first >>downloading/uploading the PTF? If you lack such connectivity, I >>don't see how you can avoid the download/upload. Or does MSM >>somewhat automate the process, perhaps to hide it completely? >> > >Currently, as far as I know, only IBM supports the functions provided >by RECEIVE FROMNETWORK or RECEIVE ORDER. > >MSM does it a little different. It automates the manual process (the >newer CA ESD process that is all disk, no "install tape") that is used >to install their products. With that process you could FTP directly to >your z/OS system if you wanted (initiate FTP "GET" from z/OS) but typically, >you go to the ca support site via web browser to download the product >and "click on it", so it goes to your workstation and then you have to >upload the pax files or binary file (SMPMCS data) to z/OS. > >Basically, MSM FTPs pax files in gimunzip format directly to your HFS / zFS >from CA and stores them there. When you "install" a product or >PTF, it allocates data sets if needed (base product install... CSIs, tgt / >dlibs, >etc.) needed), unwinds (is unpax more correct term?) the pax file and >does the SMP/E RECEIVE, APPLY and ACCEPT. > >Last night I started the process to download 2 products before I went home. >Today, I installed them both in less than 15 minutes. One of them included >a HFS / zFS file (I chose zFS) needed as one of the targets. As part >of the install process mentioned above, MSM was able to create the zFS, >format it, create my service directory and mount the zFS file system so >it was there for the APPLY. > >BTW, I had a little experience in the install part from the technology exchange >at SHARE in Denver where I went through the process of installing a product >and some PTFs myself. > >Oh, and I deleted the products (not the downloaded "catalog" files that >are used for install) so I could repeat the process. That takes a minute or >two. I plan on demo-ing MSM from my team in the next week or so and >I am just trying to learn more about the functions at the moment. > >I'll be really happy when they add the deployment feature (being able >to copy the "run libs" from the SMP/E environment to a new HLQ / volume) >next year. The process seems to fit in with the way we install >our software in the operating system group. We "deploy" ISV software >to a secondary sysres volume with indirect cataloging. So I hope there >is an option to copy without cataloging (which is what we do and then >the indirect cataloging is a one time process unless a library name >changes / is added for a new release). > >p.s. I don't work for CA. :-) > >Mark >-- >Mark Zelden >Sr. Software and Systems Architect - z/OS Team Lead >Zurich North America / Farmers Insurance Group - ZFUS G-ITO >mailto:mark.zel...@zurichna.com >z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ >Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html ---
Re: INCREASING SIZE OF VIR - VTOC INDEX RECORD
John, I have never heard of such a thing, and I think they are confused. As long as the VTOCIX is not full (or nearly so), I see no reason to expand it. I would ask them to show you some reference that backs up their performance claim. >>> John Dawes 12/24/2009 8:40 AM >>> Barry, Our Capacity performance group said that the slow response time for some volumes was caused by the small VTOCIX. The suggestion was made to increase it. 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
Accessing the SPOOL via a UNIX filesystem protocol?
This is just a curiousity question about any interest in a possible product. Not that I'm in the business (or capable) of writing such. I would love a product which somehow maps the z/OS SPOOL (JES2 and/or JES3) into the UNIX filesystem. Basically, this would be so that I could retrieve sysout data using standard UNIX tools. For example, to be able to do an obrowse, oedit or some other list/editor on a sysout. Or use a UNIX command such as "cp" or "cat" or "grep" or ... with the input coming from a sysout. Oh, and by sysout I mean either an entire job or by a particular DSID. Example: fgrep 'S0C3' /spool/? #find all S0C3 abends in the SYSLOG cat /spool/JOBNAME/jobnumber/DSID >output.file If there is any interest, how much should such a thing cost? Say, about like SDSF or EJES? I don't doubt that Ed Jaffe could write such a thing, if there is a market. And how about an add-on to this so that it could be used, like NFS, over a TCPIP connection to another NFS-capable system (like UNIX or Linux or even Windows)? Or am I the only one here who has really embraced the dark side? 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: Anyone have a clue on this EDC5057I The open mode string was invalid?
Thank you and also the person who responded off-line. Yup, "rb" fixes it. Gosh, the doc could be better. You're right, that's what it says. Do they gain some kind of points by not adding "therefore you must code a mode that explicitly requests binary"? What about an error message that actually said which two things were in conflict? Believe me, I read what I thought was every word about record I/O in the P/G and did not see that. Unfortunately, I had started with Chapter 3, "The Record Model for C I/O" which says nothing about modes. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bill Godfrey Sent: Wednesday, December 23, 2009 5:58 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Anyone have a clue on this EDC5057I The open mode string was invalid? Try "rb,type=record". It might fix your problem. According to this page of the C/C++ Programming Guide: http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/CBCPG190/2.1.1.3 "C/C++ record I/O is binary" Record I/O is what "type=record" is requesting, which probably goes without saying. Bill On Wed, 23 Dec 2009 13:47:38 -0500, Charles Mills wrote: >The open mode string, displayed just before the call to fopen(), is "r, >type=record". > >The doc mentions making sure the DISP is compatible - it's DISP= (SHR,KEEP). > >Yes, the dataset exists. > >Anyone have any clues? > >TIA -- 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
PSF z/OS from VSE
"IBM Print Services Facility (PSF) for z/OS" is described here: http://www-03.ibm.com/systems/z/os/zos/printsoftware/psfhome_z_ww.html I don't remember using PSF/zOS to convert VSE applications to z/OS. Our Prism-CS product can automatically convert PSF/VSE to JCL OUTPUT statements, something that was used in at least half-a-dozen recent projects. Prism-CS is described here: http://gsf-soft.com/Prism-CS/ -- Gilbert Saint-Flour GSF Software http://gsf-soft.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
TSSO and z/OS 1.11.
Good morning all, I am uploading the 'new' TSSO that I pulled down from the CBT updates page. Does anyone know if it Is ready to go for z/OS 1.11? Thanks up front . Regards, Claude -- 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: SYSTEM COMPLETION CODE=102 REASON=0000000C
>Both Poster (obviously) AND Waiter are Sup key 0 Yet you're using key 8 storage for the ECB? That is rarely (if ever) appropriate. Peter Relson z/OS Core Technology Design -- 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: Hummingbird screen snapshots
Gil, I don't have Hummingbird, but I do use Rumba and it has a similar 'feature' perhaps Hummingbird has something like this too. Under Options->Edit->Clipboard format, there are several checkboxes for selecting the format of the data that gets cut/pasted such as text, BIFF, Bitmap, Picture etc. I have all of them unchecked except text. Dana -- 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: INCREASING SIZE OF VIR - VTOC INDEX RECORD
Barry, Our Capacity performance group said that the slow response time for some volumes was caused by the small VTOCIX. The suggestion was made to increase it. --- On Wed, 23/12/09, Schwarz, Barry A wrote: From: Schwarz, Barry A Subject: Re: INCREASING SIZE OF VIR - VTOC INDEX RECORD To: IBM-MAIN@bama.ua.edu Received: Wednesday, 23 December, 2009, 6:41 AM I assume you meant the size of the VTOCIX dataset and not the size of the VIR in the dataset. The job matches what I use (except I don't include the VTOCIX DSN in the first step). But what makes you think the VTOCIX is undersized? The CVAFDSM macro will tell you how many VIRs are still available in the dataset. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Dawes Sent: Tuesday, December 22, 2009 7:04 AM To: IBM-MAIN@bama.ua.edu Subject: INCREASING SIZE OF VIR - VTOC INDEX RECORD Good Evening To All, We have noticed that some of the VIRs on several volumes are very small. We would like to increase the size. I am not sure if I am on the right track this is why I need your help. The VIR exsists on the volume and in order to increase the size I will need to purge it and reallocate it. Below are the 2 jobs I would like to use. Would they work? Is there another way of going about it? I would welcome your suggestions. Job to delete the VTOCIX //STEP1 EXEC PGM=ICKDSF,REGION=3M //MYVOL DD UNIT=(3390,,DEFER),VOL=SER=PROD21, // DSN=SYS1.VTOCIX.PROD21,DISP=SHR //SYSIN DD * //SYSPRINT DD SYSOUT=* //SYSIN DD * BUILDIX DDNAME(MYVOL) OSVTOC PURGE /* Job to build the VTOCIX /* //STEP01 EXEC PGM=ICKDSF,REGION=4M,PARM='NOREPLYU' //PROD21 DD DSN=SYS1.VTOCIX.PROD21,UNIT=SYSALLDA, // VOL=SER=PROD21,DISP=NEW,SPACE=(CYL,(2)) //SYSPRINT DD SYSOUT=* //SYSIN DD * BUILDIX IXVTOC,DDNAME(PROD21) /* // -- 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 __ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ -- 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: INCREASING SIZE OF VIR - VTOC INDEX RECORD
Mark, Thanks. I will try your suggestion. --- On Wed, 23/12/09, Mark Jacobs wrote: From: Mark Jacobs Subject: Re: INCREASING SIZE OF VIR - VTOC INDEX RECORD To: IBM-MAIN@bama.ua.edu Received: Wednesday, 23 December, 2009, 6:09 AM On 12/22/09 10:04, John Dawes wrote: > Good Evening To All, > We have noticed that some of the VIRs on several volumes are very small. >We would like to increase the size. I am not sure if I am on the right track >this is why I need your help. > The VIR exsists on the volume and in order to increase the size I will need >to purge it and reallocate it. Below are the 2 jobs I would like to use. >Would they work? Is there another way of going about it? I would welcome >your suggestions. Job to delete the VTOCIX > //STEP1 EXEC PGM=ICKDSF,REGION=3M //MYVOL DD >UNIT=(3390,,DEFER),VOL=SER=PROD21, // >DSN=SYS1.VTOCIX.PROD21,DISP=SHR //SYSIN DD * > //SYSPRINT DD SYSOUT=* //SYSIN DD * > BUILDIX DDNAME(MYVOL) OSVTOC PURGE /* > Job to build the VTOCIX > /* //STEP01 EXEC >PGM=ICKDSF,REGION=4M,PARM='NOREPLYU' //PROD21 DD >DSN=SYS1.VTOCIX.PROD21,UNIT=SYSALLDA, // >VOL=SER=PROD21,DISP=NEW,SPACE=(CYL,(2)) //SYSPRINT DD SYSOUT=* > //SYSIN DD * > BUILDIX IXVTOC,DDNAME(PROD21) /* > // > Thanks in advance > > > > Looks like you can dynamically increase both the index and vtoc using ICKDSF. 2.14.4.1.4 Expanding the VTOC and the index in the ICKDSF R17 Users guide. The following is an example of expanding the VTOC and the Index using the EXTVTOC and EXTINDEX parameters. //EXAMPLE JOB // EXEC PGM=ICKDSF //VOLDD DD DISP=SHR,UNIT=3380,VOL=SER=TMP121 //SYSPRINT DD SYSOUT=A //SYSIN DD * REFORMAT DDNAME(VOLDD) VERIFY(TMP121) EXTVTOC(200) EXTINDEX(16) /* -- Mark Jacobs Time Customer Service Tampa, FL To one large turkey add one gallon of vermouth and a demijohn of Angostura bitters. Shake. -- F. Scott Fitzgerald, recipe for turkey cocktail. -- 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 __ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ -- 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
C.D. Keltie is away.
I will be out of the office starting 24/12/2009 and will not return until 05/01/2010. -- 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: Assembler program calling a 'C' program with mixed case long names
Thanks for all your responses. I am now fighting with the pre-linker; it does not pick up the long mixed case names I specified using alias statements. Steve -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Binyamin Dissen Sent: 23 December 2009 18:45 To: IBM-MAIN@bama.ua.edu Subject: Re: Assembler program calling a 'C' program with mixed case long names On Wed, 23 Dec 2009 15:55:12 - Steve Austin wrote: :>Is it possible to persuade the assembler to create mixed case ESD names? :>The GOFF option allows long names, but the ESD entries are upper case. Look at the assembler ALIAS statement. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 internal virus protection system. . - This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 internal virus protection 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: Solved: Re: Hummingbird screen snapshots
> -Original Message- > > That being the case, Paste ought to be a hierarchic menu, such as: > > > >Paste-->+--> Plain text > >| > >+--> Rich text > >| > >+--> Image > >| > >+--> Audio > >| > >+--> etc. > > > > ... with layers outside the capability of the application dimmed. > > > > Naw, that'd be too flexible :-) Srsly, sure would be nice!!! > Try the following experiment. Select some of a Hummingbird/Extra! Screen and hit Ctrl-C to copy it to the clipboard. Open up a word document. Select Edit/Paste Special... If your set-up is like mine, you will see a list of available formats that can be pasted. Ray Pearce - This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 internal virus protection 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
AUTO: James Obrizok is out of the office on vacation (returning 12/28/2009)
I am out of the office until 12/28/2009. If you require immediate assistance, please contact my backup Fernando Vega on 1-404-238-4580 or Jon Regitsky on 1-404-238-3134. Thank you. Note: This is an automated response to your message "IBM-MAIN Digest - 22 Dec 2009 to 23 Dec 2009 (#2009-357)" sent on 12/24/09 0:00:03. 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
Re: JES SPOOL "quota" by user?
One of the things that SyzSpool was written to handle is situation like this. SyzSpool allows you to manage the spool and it's very inexpensive. You can set up the rules to handle "individuals" like this and have their data be maintained (off the spool) to any age that you want it to be kept, since the data is off the spool volume(s) and compressed, (or on tape if it has reached the migration age), the user can't tie things up. On the user's side, they have complete access to their data via ISPF or the Web interface. Brian -- 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
