Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
On Tue, 27 May 2008 12:17:33 -0700, Edward Jaffe wrote: >Tom Schmidt wrote: >> On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote: >> >>> You should be using 'JESINTERFACE:EVEL 2' >>> >> >> >> They spelled 'EVIL' wrong, didn't they? >> > >Mr. Knievel might disagree. :-) So you need to be a daredevil to want to use that option? -- Tom Schmidt (It allows you to skip 50 batch jobs in a single jump of a virtual motorcycle??) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Controlling the execution sequence of dependant jobs in JES2 (a suggested fix)
On Tue, 27 May 2008 10:23:17 -0700, Edward Jaffe wrote: >Gary Green wrote: >> That's if the job names used are the FTP logon userid +1 character. If they are different, the jobs are not tracked. >> >> If someone has different information, I would love to hear it. >> > >You should be using 'JESINTERFACE:EVEL 2' They spelled 'EVIL' wrong, didn't they? -- Tom Schmidt (I'm still working on EVIL1) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframes.. Extinct or still going strong ?
F wrote: > We use IMS and DB2 on z/OS today and was wondering if we should consider > moving to distributed systems like Oracle or SQL Server. > > Reason being, we are concerned about mainframe skill sets on IMS and > DB2. Also the news around many systems moving away from mainframes keeps > us wondering what to do. > This seems funny to me since my recent (past 5-10 years) experience with folks claiming Oracle and SQL Server skill sets reinforces my opinion that DB2 on z/OS is still on rock solid ground. There is a truly scary lack of "SQL Server skill sets" in today's marketplace and not much in terms of Oracle skill sets either. Nothing to bother writing home about anyway. If any company is considering a move from z/OS and DB2 to SQL Server or Oracle I would truly want to know about it. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Harry Yudenfriend - IBM Fellow
IBM Poughkeepsie's Harry Yudenfriend has recently been elevated to "IBM Fellow" for his work on System z. Congratulations, Harry! "The title of IBM Fellow is the company's most preeminent technical distinction and is granted in recognition of outstanding and sustained technical achievements and leadership in engineering, programming, services, science and technology. To further enhance their potential for innovative achievements they are given additional responsibilities in their areas of specialization. Only 209 individuals have earned this designation in the company's history and, including the newly named Fellows, 70 are active employees." -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Off-the-wall Auditor Requests (was RE: Hardware Alerts)
On Thu, 22 May 2008 14:23:53 -0500, Eric Bielefeld wrote: >I still don't see how anyone can hack a userid and password and log on to a RACF protected system. If you have security set up correctly, you only get 3 tries or so, and then the ID is revoked. If you have been successful in obtaining and cracking the RACF database (or a database copy) then you will only need 1 try -- it ought to be successful. There is no easy way to counter such a "one and done" approach - unless you either improve your database's physical security (don't let it get into the wrong hands) or also require the cracker to physically possess something presumably uniquely identifiable. (Like a physical key but usually electronic.) It isn't so much that good guys are getting harder to find as it is that bad guys are getting a little bit sneakier. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Old CICS
On Tue, 20 May 2008 12:10:40 -0500, Chase, John wrote: >> From: IBM Mainframe Discussion List On Behalf Of Lopez, Rich [ITSUS] >> >> We have been running CICS 4.2 on z/OS 1.7 for SAP R2 for >> quite some time now. > >??? > >When did CICS 4.2 exist? The only reference to a "CICS 4.2" that I can find is the TXSeries product, circa 1998. (Does Rich run it as a unix daemon on his z/OS 1.7 system, maybe?!??) Meanwhile, we have a CICS 2.1.2 region up under a z/OS 1.8 system here. (It will not die.) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cleanup a unconnected Coupling Facility
On Wed, 14 May 2008 15:42:47 -0500, Field, Alan C. wrote: >For DR we used to do this but for the last couple of years we define our >home CFs (CF1 and CF2) in the CFRM policy. We also define the DR CFs >(CF3 and CF4) in the same policy and in the structure preflist put >(CF1,CF2,CF3,CF4), > >At home the structures allocate in CF1 and CF2. When we go to DR they >allocate in CF3 and CF4. No need to delete and rebuild anything. Yes, that's what we discussed doing for our upcoming test, too. The compelling reason to do what we did this past Sunday was to establish/confirm procedures for a "Plan B" and possible "Plan C" at DR. The problem with relying on the DR CFs is that the CFRM CF entries are specific to the model and serial involved ... and are therefore too closely tied to the whims of the DR vendor. If the DR vendor du jour upgrades or replaces the CF system and give us appropriate notice then "Plan A" will work without deleting or rebuilding anything (as you say). Trouble is, that vendor planning communication hasn't been all that reliable or timely in the past. That meant that having a Plan B and a Plan C seemed like a really good idea. I don't hate the idea of defining a fresh CFRM at the DR site; I dispute the widely held belief that there is no other option. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cleanup a unconnected Coupling Facility
On Wed, 14 May 2008 07:19:34 +0200, Barbara Nitz wrote: >Given that we had done the exact same thing in the past, I don't think that there is *any* way to do 'cleanup' of the old structures. I tried all of the force commands way back when, they all got rejected. (And as that was a test plex, I could take down the actual DB2/whatever connector, so that I wouldn't accidentally catch anything wrong.) > >You cannot get rid of the connections, as that requires XES code to actually go out to the CF and issue some sort of command. Remember, the connection and the structure are *also* in the CF, not just in some control blocks in MVS. Obviously XES cannot access the CF anymore, as it is *physically* disconnected. > >Skips idea of activating a CFRM policy that does not contain the soon-to-be- gone CF and then delete the connections and structures while XES can still get at it is the right idea. The only other way is to do the initial IPL on the new CFs with freshly formatted CFRM CDSs (which incidentally we always do - guess why!). The past is the past -- perhaps you should retry your experiments with current software and see if things have changed? My experience is recent and it seems to be substantially different from yours. The old connections to old CF structures are indeed gone - without going out to the old CF to do it, so your explanation (above) seems to be in need of additional data or additional experiments. We kept our old CFRM - what we DID use was a new, different policy since the old CF had a different model number (same serial#) as the new CF. We activated the new policy, FORCEd any non-pending structures and we were good to go. My guess as to why you do what you do is because you found a path that worked for you. That's fine, but there is another path that works... for me and for Cwi, too. (Once might be lucky but more than once in a row is repeatable.) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cleanup a unconnected Coupling Facility
On Tue, 13 May 2008 14:42:12 -0700, Skip Robinson wrote: >As I said in a previous post, we've previously experienced this problem >only in DR testing where the mirroring connection is brutally interrupted >on purpose. In the case of CEC upgrade/replacement, all systems would be >shut down cleanly before hardware work begins. > >How about, just before V XCF,OFF, the SETXCF commands are issued to expunge >the troublesome--mostly DB2--structures in advance? The advantage of doing >it beforehand would be that IPLs on new hardware would then be >straightforward. This matters a lot to automation, which wants to start up >everything in a big rush. We, too, experienced this problem in DR testing. I chose to recreate the problem - and FIX it - during our z9-to-z10 upgrade since we would then have the opportunity to establish a working DR method and document it for all (of us) to see. We are still using our CFRM file from 2005. (Sysplex is relatively new to this site.) My DR view is that that "clean shutdowns" are for whimps. Perfect the error recovery path and skip everything else. Dual path is often inefficient in computer logic and it is also inefficient in human processes. It is simply amazing how that shift in viewponit can open up a lot of possibilities. (For one thing, system shutdown can be blazingly fast. Startup doesn't have to be a daily disaster if you've planned ahead.) Think of how much your automation logic would change for the better if it was ALWAYS working from the viewpoint of recovery. -- Tom Schmidt (That last paragraph should provoke some fun discussion.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cleanup a unconnected Coupling Facility
On Tue, 13 May 2008 11:38:05 -0400, Kevin Mckenzie wrote: >>DFHCFLS_SYSTCFD1 05/10/2008 22:45:55 ALLOCATED >> POLICY CHANGE PENDING - CHANGE > >What happens when you issue the command > >d xcf,str,strname="DFHCFLS_SYSTCFD1", > >and then try to delete the connections to the structure? Those are what >need to be cleaned up, the connections XCF thinks it has to the structure. > >You use the command > >setxcf force,connection,strname=,conname= > >to do this. No, I stand by my previous statement that: setxcf force,structure,strname=DSNDSNY_SCA ...should do the trick for this specific case. That is the minimum thing that Cwi needs. If they managed to pend any other commands to XCF they may also need to issue a SETXCF POLICY,START,POLNM=... command to move things forward. (We needed that for exactly that reason, too. YMMV.) -- Tom Schmidt (DB2 should then rebuild in the new structure in the new CF. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Cleanup a unconnected Coupling Facility
On Mon, 12 May 2008 23:34:11 -0500, Cwi Jeret wrote: >Attached are the Commands I used with the results. >Again, the problem is that CFRM still has the allocations on >CF2 which used to be on 2094 . >Now CF2 is on 2097, therfore the CF is not connected, preventing >any action on its structures ! ...snipped... > -D XCF,CF,CFNAME=CF2 > > IXC362I 07.06.50 DISPLAY XCF 148 > CFNAME: CF2 > COUPLING FACILITY : 002094.IBM.83.00062161 > PARTITION: 02 CPCID: 00 > SITE : N/A > POLICY DUMP SPACE SIZE: 6000 K > ACTUAL DUMP SPACE SIZE: N/A > STORAGE INCREMENT SIZE: N/A > > ALLOCATION NOT PERMITTED > POLICY CHANGE PENDING - DELETE > > NO SYSTEMS ARE CONNECTED TO THIS COUPLING FACILITY > > STRUCTURES: > DFHCFLS_SYSTCFD1(PND) DFHNCLS_PRODNC1(PND) DFHNCLS_SYSTNC1 >(PND) > DFHXQLS_PRODTSQ1(PND) DFHXQLS_SYSTTSQ1(PND) DSNDSNY_LOCK1 >(PND) > DSNDSNY_SCAIGWLOCK00(PND) ISTGNRAQ(PND) > ISTGNRBG(PND) IXCPATH2(PND) RRS_ARCHIVE_2(PND) > RRS_DELAYED_2(PND) RRS_MAINUR_2(PND) RRS_RESTART_2(PND) > RRS_RMDATA_2(PND) > > > > -setxcf force,structure,strname=DSNDSNY_LOCK1 > > IXC353I THE SETXCF FORCE REQUEST FOR STRUCTURE > DSNDSNY_LOCK1 WAS REJECTED: > STRUCTURE NOT ALLOCATED OR IS PENDING DEALLOCATION You are almost finished -- you just need to issue one more command: setxcf force,structure,strname=DSNDSNY_SCA ...and that should do the trick! -- Tom Schmidt (We had a similar issue with our shiny new z10 on Sunday morning and all we needed to do was force the structures that did NOT contain the (PND) suffix in the display. Presto!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Report: HP to buy EDS for $12 billion
Report: HP to buy EDS for $12-13 billion (possibly to be announced as early as tomorrow?) http://www.news.com/8301-10784_3-9942051-7.html -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IPCS - where to get shop specific data
On Thu, 8 May 2008 18:05:31 -0400, Rob Scott wrote: >Tom > >A very common usage of that field is store some info about the level of the z/OS system packs (eg "put level"). A site can add a simple jobstep to their sysres cloning/propagation JCL to update the field using a simple zap. Hi Rob, Some sites certainly do that but certainly not all sites, nor is the format common by any reasonable definition. Some folks stick the date (in various formats) into the field, some plant the PUT or ESO level into the field, some use both. I've seen many combinations. I have seen sites use the field to identify different systems in a shop and (in much larger entities) to identify different shops throughout the corporation. I don't know whether outsourcers make use of the field in a manner similar to Todd's idea. Smaller sites tend not to be aware or be too burdened with other work to bother updating the field at all. To Wayne's point, there is no common, standard place in any IBM-standard data structure that holds such a Universal Customer-ID value. (I agree with Wayne.) The CPUID ought to be unique (at least until PSI is able to sell their hardware). I don't see any compelling reason why customers would want to have to maintain such a value. (Customers don't see other customers' dumps so they don't have the need.) Perhaps some ISVs use the license key values to accomplish Todd's goal? -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IPCS - where to get shop specific data
On Thu, 8 May 2008 16:24:29 -0500, Todd Burch wrote: >Im making an assumption that somewhere in a control block somewhere (maybe >the CVT, ECVT, or SMF control blocks?), there is a site/company name (like >ACME Inc.) that is defined at z/OS install time. > >If this assumption is correct, where could I pick up that data in an IPCS >dump? Ive looked in the CVT, ECVT and SMCA but havent found anything yet. > >(Perspective: clients send in dumps, and I would like to output the client >data with our automated IPCS analysis routines.) There is a 16-byte field in the CVT's prefix area, at -24 decimal from the CVT base, which was set aside by IBM decades ago for such a purpose. The field's name is CVTVERID. (FLCCVT-24)->CVTVERID Please let us all know if you ever find any non-blank data in that field from any client site. (I don't expect that you will find that many sites customize that field. I won't be surprised if many on this list are unaware of it.) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
On Sun, 4 May 2008 15:39:47 -0400, Robert A. Rosenberg wrote: >At 16:23 -0500 on 05/03/2008, Tom Schmidt wrote about Re: SVC99: > >>I suspect that the problem your program is having has less to do >>with the SYSDSN enqueue that S99WTDSN was designed to cope with, and >>more to do with the SYSVSAM enqueue that Catalog management and VSAM >>use for proper serialization during the catalog compression >>processes. I do not recall any user control over that SYSVSAM >>intersect via SVC99. > >Issuing a ENQ TYPE=TEST against SYSVSAM just before the SVC 99 would >give an indication of a probable intersect problem (with the caveat >that the test assumes that the ENQ status will stay the same until >the SVC 99 is issued). I don't think that the caveat conditions will be met under the OP's circumstances. There will be intersect issues after SVC99 during OPEN as well as possible intersect issues during SVC99 processing. The catalog compression processes might well acquire/release/reacquire/re-release the various enqueues during processing, in a variable pattern depending upon the catalog's specific needs. While I'm not a big fan of WTORs in general, the process otherwise described by another poster to use WTOR & multiple ECBs and a WAIT, sounds like a workaround to OP's problem. I would use the MODIFY ECB instead of WTOR. It sounds like a messy problem to have. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SVC99
On Sat, 3 May 2008 05:58:25 -0500, Saravanan J wrote: >In one of our programs say XYZ, we are accessing USER catalog by >dynamically allocating the Catalog using SVC 99 (in shared access mode) to >get some dataset related information from the catalog. > >Before this dynamic allocation we are actually turning-on all the wait bits >(S99WTVOL+S99WTDSN+S99WTUNT+S99OFFLN) in S99FLG21 byte. So far so >good, but we seem to be getting allocation failures on the catalog in our >program XYZ, whenever our catalog compression jobs are running (Catalog >compress jobs have exclusive ENQ on the catalog during compress). > >As per our understanding, the dynamic allocation in XYZ program should wait >for the shared access of Catalog as the catalog is locked for exclusive use by >Catalog compression jobs. And since the DSN is unavailable to our program >XYZ, it should wait for the DSN till the catalog compress job releases the >exclusive lock on catalog. > >Any pointers to why the S99FLG21 wait bits are not working would be of great >help to us? I suspect that the problem your program is having has less to do with the SYSDSN enqueue that S99WTDSN was designed to cope with, and more to do with the SYSVSAM enqueue that Catalog management and VSAM use for proper serialization during the catalog compression processes. I do not recall any user control over that SYSVSAM intersect via SVC99. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Connect:Direct (NDM) CPU Usage
On Fri, 2 May 2008 12:38:52 -0400, Pinnacle wrote: >- Original Message - >From: "Craddock, Chris" <[EMAIL PROTECTED]> >Sent: Friday, May 02, 2008 12:17 PM > >> Half an engine? No. It means basically that if you sample the work over >> a period of time, that 50% of the time that the work was eligible to be >> dispatched it actually was dispatched. >> >> Arguably this is an extremely crude and ill-conceived way of defining a >> performance goal, but it's the one we were given :-( >> >>> But my point is VEL=50 is very high for an IMP=4 >>> workload (IMO). >> >> Often true, but not necessarily. (playing devil's advocate :-) > >With apologies to Crash, I gotta go with Z. Velocity 50 for an importance 4 >workload is way high. I would guess also that nothing else was impacted, so >WLM just gave the CPU to NDM. It's not a problem unless you had other >higher importance workload affected. Well, I disagree with your "it's not a problem" statement because OP said, "This caused us to hit our softcap and affected other tasks in the system." The softcap issue could be resolved by Dave Thorn's suggestion of putting it into a resource group with a max specification. Other sites may not necessarily have the bandwidth to support NDM eating half an engine; if the bottleneck is in the pipe then they won't necessarily see ugly CPU consumption. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ipsf HIGHLIGHT option
On Fri, 25 Apr 2008 12:59:56 -0500, Tom Marchant wrote: >On Fri, 25 Apr 2008 12:20:28 -0500, McKown, John wrote: > >>>Don Leahy wrote: >>> >>> I like Vista so much that I paid for it out of my own pocket and use >>> it both at home and at work. >> >>I really wish that somebody would write a native 3270 emulator for >>Linux/Intel. > >Has anyone ever asked Tom Brennan if he'd consider porting Vista to run on >Linux? Alternatively, has anyone tried to run Vista under WINE on Linux? -- Tom Schmidt (I use Vista under XP/Parallels/OS_X in 62x154 terminal mode on a 30" Cinema display... VERY easy on the eyes!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Fri, 18 Apr 2008 12:44:24 -0500, John McKown wrote: >Don't let the outsiders connect directly to the company LAN. Instead, >force them to use something like Microsoft Terminal Services to logon to >a multiuser Windows server. Once there, allow them to use a 3270 >emulator. That way, the emulator is running on the server, not on the >user's desktop. That stops IND$FILE and ftp transfers directly to the >user's desktop. I am fairly sure that it stops doing cut'n'paste as >well. What it does not stop is ftp to their share on the server, then >email the code to themselves. But this is becoming more of a PITA to the >user, which does help to discourage them. It all depends on why they are >doing it. (cost vs. benefit to them). > >This same concept can be applied to other systems such as Linux. I think that a determined programmer would just take screen shots to a file - or just take snapshots with a camera (or continuous video) to capture the data for post-processing by OCR software. (I do something very similar with my genealogy hobby... not terribly difficult or expensive if you are determined.) -- Tom Schmidt (BTW, I know of a company nearby that has a policy prohibiting cellphones with cameras but they have no prohibition regarding cameras without cellphones. You may bring in a digital camera - as long as it isn't part of a cell phone!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Fri, 18 Apr 2008 00:47:29 -0500, Kenneth E Tomiak ranted: >Tommy Tsui has had posts before, IIRC, that indicate a complete lack of >knowledge about how an operating system works. I believe he has been asking >how to audit just about everything. Ignorant of what SMF can record, how to >process SMF data, and how to report on the data. There are lots of manuals >that discuss this stuff. I believe that Tommy's past posts have shown an incomplete knowledge but I do NOT believe that they have indicated "a complete lack of knowledge about how an operating system works." I believe that you, Kenneth, have been overly harsh in your judgement of Tommy. I agree that there are lots of manuals that discuss this stuff... so many, in fact, that they become a problem for someone who is new to this particular operating system (and apparently new to computing). Tommy's posts have, IIRC, been on-topic to this particular LISTSERV and ought to be welcome here. Whether you chose to respond to them is, as always, up to you. How you respond might be a wee bit more tempered. >On Thu, 17 Apr 2008 17:11:13 -0400, J R <[EMAIL PROTECTED]> responded to Ted's earlier post: > >>> It is better to protect the data, rather than the method of copying. >> >>That doesn't help if you want the programmer to work on a program >>but you don't want him to take it with him. ...and that is the bottom line: If you hire a creative programmer to work on your software then you need to carefully assess and perhaps accept the risk that his creativity might include a method of capturing the work product for himself. There are so many ways to skin that cat that auditing any one is pointless. (Besides, someday you might lose the source and his will become the backup.) Perhaps this is more of a contract issue with the creative programmer and not so much a technical contest? We all read & post here to both seek & share our knowledge, don't we? Or have I completely misunderstood ibm-main's purpose? -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Thu, 17 Apr 2008 21:30:43 +, Ted MacNEIL wrote:
>>That doesn't help if you want the programmer to work on a program but you
don't want him to take it with him.
>
>If he can read it, he can copy it.
>And, how protecting IND$FILE will not be enough.
>There are many methods, but the crudest one cannot be protected except
by giving the programmer an old 3270 green screen (actually, take the PC
away from him (8-{>}).
>
>The crude method is to copy and paste from a TN3270 session into notepad.
...and, lest anyone think that Ted's "crude method" would be too crude to be
useful, it is trivial to create a VB program that steps through the source,
screen-by-screen, while taking snapshots that it copies to notepad (or
straight to a PC file). Grabbing several thousand lines of source wouldn't
take
any more time than it would to page through several thousand lines of source
on the screen. Many TN3270 packages may even provide sample code with
the distribution.
Either you trust your programmer's ethics or you shouldn't provide access to
the treasured source. There is no in between.
--
Tom Schmidt
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IRREVX01 strangeness
On Wed, 16 Apr 2008 14:15:32 -0500, Walt Farrell wrote:
>On Wed, 16 Apr 2008 09:46:49 -0500, Paul Whelan wrote:
>
>>I'm trying to use the RACF command exit IRREVX01 to limit the types of
>>searches submitted through a z/OS LDAP server and am seeing some very
>>strange behaviour that I can't understand. If I tell the exit to reject any
>>search command containing FILTER(*) the exit works perfectly and if I tell
>>the exit to reject any search containing FILTER(SI1*) it also works
perfectly.
>>
>>However, as we need to reject certain FILTER values I need to be a bit more
>>selective and first of all find FILTER( in the command then process the
>>FILTER argument(s) to decide whether to reject the command or not which
is
>>where I am coming unstuck. If I tell the exit to reject FILTER( (as a first
>>pass before further refining the exit to check the arguments) it does not
>>work, that is to say, it does not find FILTER(. It is also incapable of
>>finding just FILTER.
>>
>
>Your exit seems to expect "FILTER(" exactly at the end of the command
>buffer. It won't be there.
>While the FILTER keyword may be last in the buffer, the string "FILTER("
>would not be last, as the operand (e.g., "*)" ) will follow it.
>
>Assuming your earlier versions looked for FILTER(*) at the end, that would
>have worked. Or looking for FILTER(SI1*) at the end would have worked.
But
>not looking for FILTER( at the end.
The core issue with his search for "FILTER(" was identified by Binyamin Dissen
previously: the CLC in SRCHLOOP was coded as if the CLC instruction could
use 3 general purpose registers -- the "R9" in that line is what's wrong.
Either the OP needs to execute (EX) the CLC or make use of CLCL or (in this
specific case) use the correct length for the string "FILTER(" (which would be
7, not 9). Better yet for this specific case, use L'FILTER as the CLC length
so
it is computed as assembly time.
--
Tom Schmidt
(Did anyone in the State of Washington take offense to that?)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Journal - Dark Side or Bright Side
On Wed, 16 Apr 2008 11:44:38 -0700, Schwarz, Barry wrote: >While Microsoft is closer to Bellevue than it is to the Pacific Ocean, >it is no more in the former than it is on the shore of the latter. > >I wonder who should be more offended: the city of Bellevue whom you >accuse of harboring the evil empire or the city of Redmond whom you just >deprived of its largest employer Well, if either city takes offense I won't lose a wink of sleep. Neither will I lay awake an extra moment if the evil empire itself takes offense. Far too much is made these days with offense being taken. Harrumph indeed. But you are correct: Redmond is the Death Star's home. Bellevue just happens to share the area code (and more than a few homes for the Storm Troopers, making the mistake somewhat more understandable - especially from this distance). (If it were only that easy to deprive that specific city of its largest employer! That would be worth losing a few winks pondering.) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Attachements (Was IRREVX01 strangeness)
On Wed, 16 Apr 2008 11:40:12 -0500, Eric Bielefeld wrote: >Since when has IBM-Main allowed attachements. This is the first time I've ever seen one. Eric, The ibm-main LISTSERV web interface (which many of us use) has allowed attachments for quite some time now. I don't believe this recent attachment was the first but it certainly is (happily) infrequent here. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Journal - Dark Side or Bright Side
On Wed, 16 Apr 2008 07:24:01 -0700, Jon Nolting <[EMAIL PROTECTED]> wrote: >Actually, there will be one less Amdahl'er next week when I move from doing mainframe interoperability at Microsoft and start with IBM as a zITA in the Pacific Northwest next week. > >Jon Nolting >EPG Compete - CATM >Enterprise Technology Architect >(425) 707- Great news! One (more) Jedi returned from the Death Star of Bellevue. (Now if we could just get the Wookies to stop writing code for Tivoli...) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Xephon, are they still in business?
On Tue, 15 Apr 2008 13:11:47 -0500, Ian wrote: >Xephon did a great job in providing this service through the years. >But in this day and age I don't see the need for an expensive service like >this. > >If you look at the open source communities you will see lots of code and >ideas freely exchanged between users. >Apart from the several listservers the mainframe community is the only one >that lacks this kind of open exchange of ideas and code. >The listservers also provided a great servers during the years but it lacks >a structured way in categorizing and storing valuable information. > >I think its time for us(old mainframers) to jump on the "new " age >technologies like blogging, forums and wiki's to preserve our knowledge and >pass it on to the next mainframe generation. EXCUSE ME?!? The mainframe community has had (1) SHARE and (2) the CBT tape (et al) for decades - many decades. (I wouldn't lump GUIDE into the same category, but it did belong in a similar category.) The mainframe community also supported city, area and regional user groups for quite a few of its subcomponents for many, many years -- up until the advent of the internet, which brought communication without travel requirements. "Us (old mainframers)" grew up knowing how to preserve our knowledge and pass it along. Anyone claiming the contrary is woefully uninformed. -- Tom Schmidt (Me a skeptic? You'll never be able to prove that!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TIOT filling up: too many dynamic concatenations
David, Could you clarify whether you perform the concatenation just once per run, or am I understanding that you perform multiple concatenations during each run? -- Tom Schmidt On Thu, 10 Apr 2008 15:13:58 -0500, David Eisenberg wrote: >The entry that was filling up was actually not MYFILE; that entry remained at >20 bytes. The ever-growing entry seemed to contain all of the history of the >concatenated DDs. With each new allocation and concatenation, it grew >larger. > >After reading all of these very informative replies, I think that the best >course >of action for me will be to modify the application to process one file at a >time. >It may not be perfect, but it will work, and it will be scalable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSAFF card
Oh? What level of JES2 allows for a SYSAFF setting on the JOBCLASS ? INTRDR has a SYSAFF. JOBCLASS has a QAFF (at least on z/OS 1.8 JES2). But I'm not recalling any vaguely current JES2 with SYSAFF on JOBCLASS... - On Thu, 3 Apr 2008 13:44:49 -0500, Hal Merritt wrote: >Well, actually, there is no default. The action taken depends on the >SYSAFF setting for the job class. And I'm too lazy to look up -that- >default :-) > >Our scheduler runs on a 'penalty box' (an LPAR capped to save on >software costs) and submits jobs there as do our TSO users. However, all >jobs without a ROUTE are to run on the other LPAR. We do that via the >job class setting. > >We do have a few jobs that have explicit SYSAFF=ANY. > >HTH > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On >Behalf Of Bill Johnson >Sent: Thursday, April 03, 2008 10:35 AM >To: IBM-MAIN@BAMA.UA.EDU >Subject: SYSAFF card > >If you do not use a SYSAFF card thereby taking the default of SYSAFF=ANY >will a job run only on the LPAR that it is submitted from? Can it ever >run on an LPAR other than the one submitted without a SYSAFF card? > > TIA > > Bill Johnson -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IBM JRD article on DS8000 + z/OS "Adjuncts"
http://www.research.ibm.com/journal/abstracts/rd/524/chambliss.html [They] describe the design of a prototype system by which the IBM DS8000™ storage system can host application extensions, called Adjuncts, that improve the operation of z/OS® (mainframe) applications. These extensions process large amounts of data in operations like searching, sorting, and indexing, so that the host application need not even access most of the data. -- Tom Schmidt (I apologize for the on-topic post here -- I'm sure other regular posters will generate enough noise to bury it in practically no time at all.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Tivoli Monitoring (ITM for short) (was: Is IBM/Tivoli turning into CA?)
On Mon, 3 Mar 2008 12:03:31 -0500, Andrew McIntyre wrote: >I'll respond to each item below starting with >>>. > >Bruce Hewson wrote: >> Hello Andrew, >> >> And so we have a case of us customers being ignored... :-) >> >> The PC I use has only got Company mandated and wrapped products installed. >> > >>>You can use the TEP browser interface if you like, instead of the >TEP Desktop Client, so there's no software to install on your PCs. NOT true, Andrew! IBM/Tivoli TEP mandates the use of IBM Java 1.4.2 when you use the TEP browser interface. My company's standard Java is SUN's and TEP's use of IBM Java represents an abberation for our standards (plus more difficulty with external security mandates). TEP's requirement for 1.4.2 is at odds with other IBM software that requires 1.5, but that's another matter; my desktop has to support 2 Java vendors and that's at least one too many. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: new Feb2008 zPOP: Execute Relative Long
On Mon, 3 Mar 2008 10:17:24 -0600, McKown, John wrote: >> -Original Message- >> From: IBM Mainframe Discussion List >> [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe >> Sent: Saturday, March 01, 2008 1:01 PM >> To: IBM-MAIN@BAMA.UA.EDU >> Subject: Re: new Feb2008 zPOP: Execute Relative Long >> >> Tom Schmidt wrote: >> > See SA22-7832-06 for the EXRL instruction. >> > (I'm sure Ed's been aware for several months now, but the >> rest of us may be happy now.) >> >> Give 'em an inch and they'll take a yard! People are already clamoring >> for additional forms of EXRL that can "OR" the mask with other than byte >> one of the target instruction! It never ends! :-) >> >> -- >> Edward E Jaffe > >How about a totally new EX type instruction. This one executes the >single instruction built into a 64-bit register. This could handle any / >all instructions from 2 to 8 bytes in length. And since the largest >instruction is 6 bytes long, that is all of them. Just create the >instruction in a register, then "execute" the register contents. Why not also allow the EXreg instruction to execute UP TO 8 bytes worth of the register contents? In other words, if you have less than 6 byte instructions to execute (say a 2-byte plus a 6-byte instruction) why not allow BOTH of them to potentially execute within the single EXreg instruction? Then why not also allow an EXreg-multiple instruction to support up to 16 (or 15) registers worth of instructions preloaded into the registers to operate, much like the PDPs of old did? (Not that slow, of course.) Or just leave it all alone and be grateful that Ed got his wish. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z10 LSPR
On Thu, 28 Feb 2008 06:33:01 -0600, Tom Marchant wrote: >On Wed, 27 Feb 2008 17:31:04 -0500, Arthur T. wrote: >>[EMAIL PROTECTED] (Tom Schmidt) wrote: >> >>>>The z10 LSPR data is now available too. >>>> >>>>http://www-03.ibm.com/servers/eserver/zseries/lspr/ >>> >>>Yes, and it looks like they are using a new "femtofont" on >>>the z10 page. >>>(Could they make it smaller still?) >> >> I don't see what your complaint is. The font is a >>full 4.5 points; Word supports down to 1 point. > >And IBM Writer (Is that what it was called?), packaged with OS/2 could >support down to 0.2 point. > >Seriously, though, it looks like the the same size font to me. It depends -- if you print the LSPR report from the .PDF the z10 information on page 85 was forced (by IBM) to fit on a single page and they used their new femtofont to make all of the configurations fit. I suppose that's fair since the numbers are almost legalese so small print is what it is all about, right? -- Tom Schmidt (When I viewed the page on my 30" cinema display I didn't have issues.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z10 LSPR
On Wed, 27 Feb 2008 14:57:37 -0600, Tom Marchant wrote: >The z10 LSPR data is now available too. > >http://www-03.ibm.com/servers/eserver/zseries/lspr/ Yes, and it looks like they are using a new "femtofont" on the z10 page. (Could they make it smaller still? Is that why IBM is experimenting with the physical manipulation of single atoms - to be able to fit oodles of atomic-sized lines onto a single sheet of paper for the 2013 version of LSPR?? We'll see.) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
new Feb2008 zPOP: Execute Relative Long
See SA22-7832-06 for the EXRL instruction. (I'm sure Ed's been aware for several months now, but the rest of us may be happy now.) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Has IBM provided a link to the z10 POPs?
On Tue, 26 Feb 2008 18:42:05 -0500, George Young wrote:
>Binyamin Dissen wrote:
>> Has IBM provided a link to the z10 POPs?
>
>Go to the IBM Publications Center
>
>http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss?CTY=US&null&;
>
>and search for SA22-7832-06 and you'll find it.
Whoo-hoo! I won't be able to get much sleep tonight!
Thanks!
--
Tom Schmidt
("The new phone books are here, the new phone books are here!")
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM Preview of z/OS V1.10
On Tue, 26 Feb 2008 13:25:13 -0500, J R wrote: >"A new virtual storage area, the High Common Storage Area (HCSA), is defined." > >Did they really call it that? Or, did they mean to say, "High Common *Service* Area"? > >> Date: Tue, 26 Feb 2008 11:53:36 -0600 >> From: mark.zelden >> >> HCSA - because 510T of shared storage is not enough. :-) >> Yeahbut... what happened to 'Grande' in the naming scheme? -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: System z10 announcement (in English)
On Tue, 26 Feb 2008 12:00:33 -0600, Staller, Allan wrote: >John, > >Sounds like things are looking up for you! > It seems as if the longevity of the managers at John's shop is about 12-18 months (about the life of a typical CIO). Give this guy some time and he'll be out of there, too. Right, John? -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: System z10 announcement (in English)
On Tue, 26 Feb 2008 11:37:02 -0600, McKown, John wrote: >> -Original Message- >> On Behalf Of Tom Schmidt >> Subject: Re: System z10 announcement (in English) >> >> On Wed, 27 Feb 2008 00:05:16 +1000, Shane wrote: >> >> >Nice green stripe. >> > >> >"Big page" only 1 Meg. Interesting. >> ... >> >anything else of interest ??? ... :0) >> >> Hmm... is it interesting that it doesn't do Windows Server (yet)? >> >> -- >> Tom Schmidt > >[shudder] > >From what I've read, you can run Windows on a zArch machine using the >BOCHS emulation code. Now, why would I want to put the world's least >reliable OS onto the world's most reliable hardware? Funny you should ask. Maybe because many of the Windows (Server) outages had to do with non-parity memory? Or because of the memory protection schemes used (or not) on other hardware? Or because it blends in nicely with that whole green stripe thing on the front of the z10 box??? (I don't see IBM devouring its own children with the z10 announcement - AIX and pSeries boxen seem safe to buy (for now); I see the z10 attempting to make advances on the HP and Sun boxen. Solaris can be run on the z9 but I'm not at all sure there's anything worth keeping in HP-xX, is there?) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: System z10 announcement (in English)
On Wed, 27 Feb 2008 00:05:16 +1000, Shane wrote: >Nice green stripe. > >"Big page" only 1 Meg. Interesting. ... >anything else of interest ??? ... :0) Hmm... is it interesting that it doesn't do Windows Server (yet)? -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: System z10 announcement (in English)
On Wed, 27 Feb 2008 00:05:16 +1000, Shane wrote: > >anything else of interest ??? ... :0) AutoIPL! (At last!) "AutoIPL support will provide the capability to request that the system automatically IPL stand-alone dump, z/OS, or both, when a disabled wait state is requested by a system component. This function is designed to be under the control of new parmlib parameters and a new Wait State Action Table (WSAT); together, they specify the actions, if any, to be taken for various disabled wait states. In a sysplex environment, the Sysplex Failure Manager (SFM) policy can result in actions that load disabled wait states on systems to be partitioned out of the sysplex, which can also trigger AutoIPL processing. New options on the VARY XCF operator command will allow you to request a SADMP, z/OS IPL, or both, after the indicated system has been removed from the sysplex. AutoIPL capability is intended to help you achieve faster failure data capture and recovery after system failures." -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: System z10 announcement (in English)
On Wed, 27 Feb 2008 00:05:16 +1000, Shane <[EMAIL PROTECTED]> wrote: >Nice green stripe. > >"Big page" only 1 Meg. Interesting. >HiperDispatch ... way overdue. >16 Gig HSA. > >anything else of interest ??? ... :0) Curiously missing today is a new z/VM announcement or "preview". But there is some interesting foreshadowing for what could be z/VM v6.2 with the Statement of General Direction section regarding the to-be-announced "z/VM" LPAR mode... it looks like HiperDispatch and z/VM vN.R may become rather cozy. I'm surprised by the "only 1 Meg. Big page" delivery, too. Many competitive OS's support larger 'big page' sizes... even AIX allows for much bigger pages, doesn't it? (ISTR 16MB) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
System z10 announcement (in English)
http://www-01.ibm.com/common/ssi/cgi-bin/ssialias? infotype=AN&subtype=CA&htmlfid=897/ENUS108-154&appname=USN -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Z10 coupling link
Not necessarily so -- all NDAs are not created (or maintained) equally. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Z10 coupling link
Hmmm... z/OS 1.10 (on page 4) AND the z/10-EC (on page 5). Nice find, Mark! On Wed, 20 Feb 2008 14:19:01 -0800, Mark T. Regan, K8MTR wrote: >Go to > >http://www-1.ibm.com/support/docview.wss?uid=tss1prs840 > >and select the presentation labeled S2885BB - Tool Bag - orlando.pdf > >See page 5. > >Mark T. Regan, K8MTR >CTO1 USNR-Retired (1969-1991) > > >- Original Message >From: Tom Schmidt <[EMAIL PROTECTED]> >To: IBM-MAIN@BAMA.UA.EDU >Sent: Wednesday, February 20, 2008 2:42:32 PM >Subject: Re: Z10 coupling link > >On Wed, 20 Feb 2008 13:04:19 -0600, Paul Meier wrote: > >>Does anyone have any idea how to circumvent the problem with connecting >the >>current coupling links from a z900 STI to the new z10 infiniBand link? OR >>have an idea how to integrate the two? The problem is coupling a z900 to a >>new z10. > > >You might want to ask your question again AFTER next Tuesday, Feb. 26th, >since a 'z10' has not been announced just yet. (Rumored heavily, sure, but >not announced.) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Z10 coupling link
On Wed, 20 Feb 2008 13:04:19 -0600, Paul Meier wrote: >Does anyone have any idea how to circumvent the problem with connecting the >current coupling links from a z900 STI to the new z10 infiniBand link? OR >have an idea how to integrate the two? The problem is coupling a z900 to a >new z10. You might want to ask your question again AFTER next Tuesday, Feb. 26th, since a 'z10' has not been announced just yet. (Rumored heavily, sure, but not announced.) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Price of CPU seconds
On Tue, 19 Feb 2008 16:30:03 +0100, Miklos Szigetvari wrote: >For me this more or less clear. >I have here a number of collegues from NT and Unix , and they don't >understand why the 0.5% CPU time is a matter: > >/"Would somebody knowledgeable please explain to me why some host people >get their panties in a knot (I love colorful expressions!) over a few >dozen MBs and a CPU usage of 0.5%? Are there real reasons for this, or >are they simply stuck in a 1960s mindset? How much can 408 CPU-seconds >per day cost?" >/ The question really needs to be researched from a different perspective: Does this 408 CPU-seconds come from (1) a peak time of day, or (2) is it evenly distributed throughout the entire 24 hour period, or (3) is it primarily from off-peak (overnight) timeframes? If it is the first then the cost is substantially higher than it appears when just looking at raw numbers - even to their mindset. If it is the second then the cost is still relatively expensive during peak and is a (small) contributor to earlier upgrades and higher software license fees. If it is the third - using primarily unused or "mop up" cycles then it isn't so bad - even with a 1960s mindset. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COTS software on box ? to replace mainframe was Re: Curious(?) way to ZIP a mainframe file.
On Wed, 13 Feb 2008 20:00:38 -0700, Steve Comstock wrote: >Clark Morris wrote: >> On 13 Feb 2008 08:21:59 -0800, in bit.listserv.ibm-main John wrote: >>>>-Original Message- >>>>On Behalf Of Steve Comstock >>>>Sent: Wednesday, February 13, 2008 8:49 AM >>>>Subject: Re: Curious(?) way to ZIP a mainframe file. >>>> >>>>McKown, John wrote: >>>>[snip] >>>> >>>The current management still says that it is going away (despite the >>>fact that the workload is growing). They base this on the plan to >>>replace the mainframe software with COTS software running on other >>>platforms such as Linux (Windows is now considered to be "also ran" >>>around here). They just haven't really found the COTS software that they >>>need yet. >> >> >> Unfortunately even if the mainframe were considered, the probability >> of finding COTS software that both meets the business need and runs on >> the mainframe is slim. > >Sorry. What is COTS? COTS == Cheap, Off-The-Shelf (software in this case; it can also apply to hardware... and even to people.) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM PR: Almost Introducing the Extraordinary New XXXXX
On Tue, 12 Feb 2008 22:49:18 -0600, Michael Stack wrote: >It's nice that this announcement coincides with the X meeting in Orlando >that week. Should we presume that there will be sessions on X at the X meeting? I'd guess yes since John Eels' presentation at 11am on Feb 26th says (or said) that his presentation would be announced prior to the session. (I read that as confirmation that the announcement would be sometime prior to 11am on 26Feb.) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 2097?
>On Tue, 12 Feb 2008 16:10:10 -0600, Tom Moulder wrote: > > CPC NAME = ZHE > z/HE might be a name used if the new box was closer to the size of a washing machine than a refrigerator; my washer is a High Efficiency model (HE)... so why not the next mainframe? (One reason not to go that route might be that the HE washers use very little SOA(P). Yes, the are environmentally friendly - very "green" (low water, lower power, low detergent) but isn't IBM Global trying to sell mostly SOAP services?) -- Tom Schmidt (Nope, no NDA... just speculation.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 2097?
On Tue, 12 Feb 2008 21:20:22 +, Ted MacNEIL wrote: >The z9EC model number is 2097. No, it isn't. The z9EC model number is 2094; the z9BC number is 2096. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS system programmer staffing
On Tue, 12 Feb 2008 10:34:15 -1000, Stephen Y Odo wrote: .. >I think we're overworked. But the plan was that we'd only have to carry >this workload for 5 years and then the mainframe would be gone and we'd >go back to normal workloads when we get integrated into our 18-man >Sun/Solaris SysAdmin pool. We've been doing this for 18 years now ... >and management is projecting that we'll only need to do this for another >3 years ... Lets see: 5 is to 18 as 3 is to ... 10.8? (Not quite 'dog years' but you are more than halfway there.) (Or do you retire before then?) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU time differences for the same job
On Wed, 6 Feb 2008 07:57:40 -0600, McKown, John wrote: >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of Phil Smith III >> Sent: Wednesday, February 06, 2008 4:45 AM >> Subject: Re: CPU time differences for the same job >> >> No, you aren't. HPO 3.4 added "Active Wait", which was >> interesting enough that it was granted a patent (cf. >> http://www.freepatentsonline.com/4631674.html). Modern VMs >> use the TPZI instruction (Test Pending Zone Interrupts), >> which basically says "Mr. PR/SM, please wake me up when I >> have something to do". Without it, PR/SM wouldn't work real >> well. (ObAnecdote: there were plenty of DOS-based PC >> programs that polled -- typically for keyboard interrupts -- >> in a fashion conceptually similar to Active Wait, and were >> really poor citizens under Windows until cured.) >> > >[snip] > >> ...phsiii > >TPZI??? Yet another undocumented System z instruction? Ah, yes, that reminded me of where I learned of it. If you want (some) documentation, check the U.S. Patent Office. Do a search on 'TPZI' and you will hit some of the PR/SM filings... and even learn of yet another undocumented (beyond the patents) instruction in patent 4843541: DCSI -- Diagnose Compare and Swap Instruction (Now if I could just keep the PR/SM stuff in memory and purge the obsolete active wait junk...) I believe that some of it (at least) was also described in an article for the IBM Systems Journal and there was also a very difficult to obtain IBM manual on SIE. I ordered my copy online maybe 12 years ago or so and I was told by IBM that they actually swiped a copy of someone's desk in POK to be able to fulfill my order. (Sorry about that, whomever it was! I still have the pub even though it is pretty long in the tooth now.) -- Tom Schmidt (Thanks, Phil!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU time differences for the same job
I've been running VM more off than on since PLC 5 and I'm certain that the behavior that I referenced WAS in VM... at some point. But if you & Lynn Wheeler say it isn't there now, I'll believe you (unless/until I can prove you wrong, of course). But I know back in the VM/HPO or (maybe) early VM/XA days it was true that VM put itself into a tiny loop while it waited for work. The loop was in a unique-to-VM PSW key so that the hardware monitor (the "speedometer") could tell the difference between work and wait. Or am I the only person who "remembers" that? -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CPU time differences for the same job
On Tue, 5 Feb 2008 14:16:08 -0800, Norman Hollander on h-WiZ.biz wrote: >Physical heat. But then I suppose it wouldn't be getting hot if it were in >a wait state. So practically speaking, I guess YES to both. You are exhibiting a z/OS bias! z/VM "waits" with a CPU loop (so it doesn't need to come out of a wait state when it is waiting) so it would run just as hot when it was idle as otherwise. (Unless there is special code to account for machine perspiration?) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New Opcodes
On Fri, 25 Jan 2008 13:12:22 -0800, Keith E. Moe wrote: >Second, there was one mnemonic that caught my eye. I do not know what it does, but it's probably one that none of us will forget: PTF. Are you certain that it wasn't PTFF (which was already described in the current Principles of Operations -05 pub)? If so there's no NDA worries. I'm still waiting for MVCOS to finally make it out into the PoO... it was "leaked" pretty thoroughly a few SHAREs ago in several IBM sessions but didn't make it into either of the last 2 PoOs. (I don't care about what issues caused it to be late, I just want it to be born after all this time.) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question on 64 bit
...so are you going to jump from z/OS 1.4 to 1.9 ? Or 1.8? -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New Opcodes
On Tue, 29 Jan 2008 12:54:53 EST, Ed Finnell wrote: >Message dated 1/29/2008 7:49:27 A.M. CST, m42tom-ibmmain writes: >> >>I know that there are a few not >>listed in the POO. Still, it sounds like it's a lot over 50. > >Those are just the graphics and sound instructions for the GDDM replacement? Oh, that makes sense -- the new PTF instruction must mean: Play The Flute (or Play The Fiddle?) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Parm Length restriction was Re: Using an InfoPrint 6500 with PSF
On Fri, 25 Jan 2008 10:40:43 -0600, Paul Gilmartin wrote: >>> >On Thu, 24 Jan 2008 18:07:41 -0600, Paul Gilmartin wrote: >>> >>I HATE JCL! > >I invite any IBM representative participating on this list to >defend such divergence of conventions; I expect a conspicuous >silence, much less an apology to customers. Why not end your constant ranting and submit a requirement to IBM Marketing or SHARE (or your favorite other user group, if any) so that you are using the official channels and NOT wasting everyone's bandwidth on ibm-main??? Seriously! -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Wheeler Postings (Was: How does ATTACH pass address of ECB to child?)
Lynn has answered that question a while ago. Check the archives. (His or ibm-main's) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Re-hosting IMB-MAIN (was RE: z890 2086-160 w/ 2 IFLs on eBay)
On Fri, 18 Jan 2008 13:18:41 -0600, tony babonas wrote: >Why don't we take up a collection to buy an old CPU, zOS and all else >needed, then host IBM-MAIN, RACF-L, CICS-L, VM-L, DB2-L etc etc. >Manpower to support it shouldn't be an issue. > >Possible? Would be a great proof of concept. How much would each of us >have to pony up? > >Imagine the possibilities. Maybe IBM, CA, BMC, FDR et all would be willing >to help out. You have completely missed the point: the list owner (Darren, in our case) is the true fundamental value to this list. The hardware & operating system are meaningless in our context. The site hosting that hardware/OS is providing us with funding (mostly, lately, to enable pointless off-topic meanderings... but I digress) but it is their funding of the list owner's salary that is the real deal. Moving (or even _thinking_ about moving) somewhere else - without Darren - is borderline blasphemy! -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VTOC Fmt6 (just curious)
On Mon, 31 Dec 2007 19:46:39 +0100, R.S. wrote: >What was Fmt6 for ? >Disclaimer: I know it is obsolete and no longer used. It was for split-cylinder allocation. It hasn't been supported (or needed) in many years. Check the IBM-MAIN archives for additional information - it has been discussed here before. >Happy New Year And the same to you! -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM question.
On Mon, 17 Dec 2007 11:16:00 -0600, Aaron Walker wrote: >http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10609 > >Abstract: z/OS 1.9 introduced new support to improve z/OS availability. >The support, called blocked workload support, is intended to allow >small amounts of CPU to be allocated to workloads which are CPU >starved. This support will be rolled back to both z/OS 1.8 and z/OS 1.7. >This document describes this new support and discusses the processor >capacity which will be potentially allocated to the function. Also this >flash will discuss new recommendations which are being made which >will change the recommended default settings for this function for all >applicable releases. Aaron, thanks! In our often CPU-starved environment we have occasionally (i.e., too often) seen issues with PDSE lockouts that can cascade into very unfortunate near outages. The APARs referenced appear to be a fit for our issues. (Time will tell, of course.) The APARs have been rolled back to z/OS 1.8 at least. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM question.
On Mon, 17 Dec 2007 11:27:43 -0600, McKown, John wrote: >> -Original Message- >> Sent: Monday, December 17, 2007 11:23 AM >> >> >> Two words: resource groups. >> >> >> I am generally opposed to resource groups, however, they do have their >> uses. I find them useful for your purpose (guaranteeing a minimum amount >> of service). I do not find them useful for "capping" a workload. >> >> The drawbacks I see are: >> >> 1) The specifications are in RAW service units( last I heard) rather >> than weighted service units. >> >> 2) They must be constantly adjusted whenever a processor changes. > >In z/OS 1.8, it appears that I can make an RG based on CPU% instead of >MSUs. Yes - and it works magically for the specific purpose you have in mind. (At least it did for us for the same kind of thing recently, also under z/OS 1.8.) The CPU% is of the total - if you have more than one processor then your total is more than a single engine, so adjust your calculations accordingly. (We have a 6-way and were off by a factor of 6 until we adjusted; then it hit spot-on and worked nicely since then.) Sorry to see your sysplex disappear over this... ;) -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM question.
John, Two words: resource groups. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
OA21346 for JES2 Dynamic Exit support - status??
Does anyone have any idea when the APAR for JES2 Dynamic Exit reload support (OA21346) is likely to close? Today's status display (from IBMLink) is quite anemic (no projected close date at all; which seems odd to me). I was under the impression that it was supposed to be released into the wild before now. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BatchPipes Hipersocket stage?
On Wed, 5 Dec 2007 19:41:42 +, Martin Packer wrote: >Tom, did you ever get any offline responses to this? > >By the way I feel a blog entry on BatchPipeWorks coming on. :-) Martin, No responses from that or from another recent request for information. (Apparently I'm either off where the trains don't run -again- or else the information was viewed by others potentially holding it as 'strategic' and non- shareable. I'd bet on me being off where the trains don't run.) I would have thought that a pure JCL high speed DD-to-DD file connection across LPARs would have been used more often "in the wild". I know (from my days inside) that there was at least some interest/use in socket connections between BatchPipes and AIX boxen (since I wrote an APAR to fix the odd case of a zero-length logical record coming in from AIX; BP supported it after the APAR.) (*shrug*) I guess people are happy writing data to storage, using FTP to ship it from storage to storage via sockets, then reading it back into a program. ALL that FTP I/O is unnecessary overhead. Without BP, to paraphrase Popeye the Sailor, "Well SLOW me down!" -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: T3 Sues IBM To Break its Mainframe Monopoly
On Tue, 4 Dec 2007 12:46:55 -0600, Paul Gilmartin wrote:
>On Tue, 4 Dec 2007 10:12:40 -0600, Doc Farmer wrote:
>>
>>Come on, IBM! Make that software available to IBM-MAIN'ers, RACF-L'ers,
>>etc., for $100 a pop, and you'll be able to make at least $20 profit on each
>>
>One PMR on such a system would put IBM in the red. Who would pay for
>software support? How much? Some developers would likely freeload for
>service on supported systems to which they have or pretend to have
>access, not a welcome prospect for IBM.
IBM has been implementing the 'solution' to that for the past year or more:
There will be no PMRs from home customers since the 3270 interface reached
its sunset a while back. All future customers will be required to use IBMLink!
All IBM has to do is disallow home customers from using the 1-800-IBM-z/OS
support line and there is no support issue left to "solve".
But I wonder if the SOHO z/OS support issue could be really addressed by
assigning it to a third party company ("SOHO z/OS Support, LLC") and then let
them come up with a business model that works for customers, themselves
and IBM? (Maybe that's something that FSI already proposed to IBM?)
--
Tom Schmidt
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: T3 Sues IBM To Break its Mainframe Monopoly
On Tue, 4 Dec 2007 12:46:55 -0600, Paul Gilmartin wrote: >On Tue, 4 Dec 2007 10:12:40 -0600, Doc Farmer wrote: >> >>Come on, IBM! Make that software available to IBM-MAIN'ers, RACF-L'ers, >>etc., for $100 a pop, and you'll be able to make at least $20 profit on each >> >One PMR on such a system would put IBM in the red. Who would pay for >software support? How much? Some developers would likely freeload for >service on supported systems to which they have or pretend to have >access, not a welcome prospect for IBM. The C-note customers would need a pay-as-you-go service model, not unlike the PC support today. (Either accept it as broken, prove it to be a manufacturer error (in which case the call is free), or pay for education via PMR.) Allowing developers to freeload isn't a bad thing -- at least it is a developer working on the mainframe platform. I can count the number of successful small mainframe developers today on the fingers of my third hand... and I only have two hands. :( -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TSO - Automatic notify messages after log on
Angel, And did you then check for the system exits that I mentioned? -- Tom Schmidt On Mon, 3 Dec 2007 18:02:00 -0500, Angel Tamayo wrote: >Thanks for your responses. > >I have access to the old system in other LPAR and the displays of the >command D IKJTSO,SEND are exactly the same, there is no differences. But in >the LPAR with z/OS 1.7 works and in LPAR with z/OS 1.8 doesn't work the >automatic notification. > > >2007/12/3, Tom Schmidt <[EMAIL PROTECTED]>: >> >> Angel, >> >> If you have access to both the old and new systems, please issue: >> >> D IKJTSO,SEND >> >> Review the displays for differences. If there are no (zero) differences >> then >> you might want to see whether the old system was using one (or more) of >> the >> IKJEESnn or IKJVSNXn system exits. (They provide for site modification of >> SEND, OPERATOR SEND and LISTBC processing. See z/OS VvRr.0 TSO/E >> Customization manual for dirty details.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TSO - Automatic notify messages after log on
Angel, If you have access to both the old and new systems, please issue: D IKJTSO,SEND Review the displays for differences. If there are no (zero) differences then you might want to see whether the old system was using one (or more) of the IKJEESnn or IKJVSNXn system exits. (They provide for site modification of SEND, OPERATOR SEND and LISTBC processing. See z/OS VvRr.0 TSO/E Customization manual for dirty details.) If you only have access to the new system, then please issue and post the results of the system response to 'D IKJTSO,SEND' and someone will likely notice what is (and is not) happening. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Transactional VSAM (DFSMStvs) question - performance
On Fri, 30 Nov 2007 09:28:08 -0600, McKown, John wrote: >Does anybody have any statistics about how much impact (slowing down of >the batch program) using "Transaction VSAM" for accessing VSAM data in >batch would have compared to accessing the same data without it. Any >comparisons with SYSB from H&W? John, Do you have a coupling facility? (My understanding was that you don't.) If you do not have a coupling facility you will not be able to use DFSMStvs (Transactional VSAM) since it requires RLS, which requires a CF for at least 2 structures. I expect that you knew that but this stuff is archived. We have found (just this month) that the elapsed time for the batch job is sometimes unchanged and other times it actually ran faster with DFSMStvs. The CPU time is much more difficult to measure, since SYSB's CPU time is spread across a lot of components. From the measurements that we have, we believe it to be approximately equal (hard to guess what the VTAM & CICS dispatcher overhead for the SYSB stuff actually was). The clear advantage of DFSMStvs is that it does not burden the CICS QR TCB with the batch job's VSAM file processing while still maintaining data buffer coherency and integrity. It does what it says it does without hurting transaction throughput. -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
BatchPipes Hipersocket stage?
Hello All, Is there anyone willing to speak of using IBM's BatchPipes with a IP socket stage which they are (or were) using to connect LPAR-to-LPAR via hipersockets? -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBMLink's unavailability
On Tue, 13 Nov 2007 16:17:26 -0700, Roger Bolan wrote: >Just from personal experience, I sometimes find that IBM web pages are >changed in ways that make them totally inaccessible to me (like it won't >let me log in even though the information I give is correct). Sometimes, >with some pages, it helps to blow away my cookies and temporary internet >files and try again. I don't know why. I can't explain it. It may not >be at all applicable to you in this case. I just know it sometimes helps >me. Indeed, that is what the IBMLINK Help Desk has had me do on a few occasions. (And, yes, it worked at least once.) I have serious issues with that approach: (1) it is based fundamentally on superstition and not on reasonable debugging techniques, and (2) it presumes that the other cookies on my desktop have no value to me or to my other vendors/users/systems. I require that IBM provide MUCH better service than this. Failing that, I don't see a happy future for IBM mainframe products. (Presumably IBM's agenda with IBMLINK's reliability issues is to lower the service stability of the mainframe to match that of the other, non-mainframe platforms. Whether that was IBM's intent or not, that is without a doubt the result that is being achieved.) "IBMLINK makes me toss my cookies" -- who wants to make that into a button for the next few SHARE meetings? (Barry?) An IBM-supplied method that would remove ONLY the specific offending cookie would be preferred. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance comparison: Hiperbatch, BLSR, SMB?
On Mon, 12 Nov 2007 14:15:08 -0500, Farley, Peter x23353 wrote: >> -Original Message- >> From: ITURIEL DO NASCIMENTO NETO >> Try using COFDMON programs that can show you who is currently using >> hiperbatch at the moment. The source code is in SYS1.SAMPLIB and used >> to work pretty fine. > >That looks like a very interesting program. Unfortunately, it requires >authorization and authority to run it. From the comments in the COFDMON >main program: > >Restrictions: > > - COFDMON must reside in an APF-authorized library or in the LNKLST. > - COFDMON must be linkedited with AC=1. > > - The following IKJTSOnn parms must be set: > AUTHCMD NAMES(COFDMON) > >Not having access to an authorized library nor authority to change TKJTSOnn >parms, I would not be able to run it anyway. Peter, You can run it, you just can't perform the linkedit yourself; find a friendly sysprog to do that for you and then you ought to be good to go. -- Tom Schmidt Madison, WI (What ever happened to Bala and Ziggy, anyway?) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
On Wed, 7 Nov 2007 12:25:45 -0600, Tom Marchant wrote: >On Wed, 7 Nov 2007 12:13:24 -0600, Tom Schmidt wrote: >>On Wed, 7 Nov 2007 11:54:58 -0600, Tom Marchant wrote: >> >>> The hightest address below the line is x'00FF'. >>>The first address above the line is x'0800'. >> >>Check your hex arithmetic: The first address above the line should be >>x'0100'. > >Yikes! Thanks for the correction. At first I thought that you were creating a mini-bar... I liked that idea except that it would still be a dry mini-bar. :( -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
On Wed, 7 Nov 2007 11:54:58 -0600, Tom Marchant wrote: >No. That would be a 28-bit address. A 31-bit address can go up >to x'7FFF'. And the line is at 16 MB, determinied by the maximum >24-bit address. The hightest address below the line is x'00FF'. >The first address above the line is x'0800'. Check your hex arithmetic: The first address above the line should be x'0100'. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
System 360 EBCDIC vs. ASCII (was Re: High order bit in 31/24 bit address)
On Tue, 6 Nov 2007 17:29:10 -0800, Edward Jaffe wrote: >I would also add that -- with 21st century hindsight and certainly not a >design mistake per se -- it sure would have been lucky if they had >standardized on ASCII instead of EBCDIC! I think that the 360 lineage would have been less likely to have survived to the 21st century if IBM would have standardized on ASCII back then. The predictions of the mainframe's demise by the early to mid 1990s might have come true if the corporate/legacy data had not been held prisoner by EBCDIC. EBCDIC bought IBM time to rethink the role of the mainframe. -- Tom Schmidt Madison, WI (Think of all the processing cycles that were sold by all competing camps performing the code page transformations.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High order bit in 31/24 bit address
On Tue, 6 Nov 2007 19:56:07 -, Phil Payne wrote: >I had a word with Gene Amdahl about it once - he said the word 'algebraic' in the BXLE/BXH >definition was the biggest mistake in the /360 design ... ...which makes one wonder: What was the second biggest mistake in the /360 design? -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFSMStvs logs - Is DASD-only a possibility?
On Thu, 1 Nov 2007 13:28:24 -0500, McKown, John wrote: >The book says you can. Doh!! Thanks, John! -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
DFSMStvs logs - Is DASD-only a possibility?
We're looking to activate DFSMStvs and since we are doing this in a monoplex (single-LPAR sysplex) we are wondering whether TVS' logs need to use CF structures or if they can possibly be defined DASD-only. The examples use CF structures of course but are they actually required? Has any other site successfully used the DFSMStvs primary & secondary logs without any associated CF structures? We are wondering since the DFSMStvs log code was cloned from the CICS log code and CICS allows for either CF or DASD-only. (Depending on the year that the code was cloned it may or may not allow for DASD-only, I suppose.) -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PL/S ??
On Wed, 31 Oct 2007 14:32:23 -0500, McKown, John wrote: > I don't even think that there is the equivalent of a Language Reference >manual around for it that is not INTERNAL USE ONLY. It was listed as "IBM Confidential - Restricted" which meant that it required you to sign for your copy (on an annual basis) several years ago, but all of that may well have changed in the past decade or so. (Your manager and his manager had to sign for you to get access (annually) then, too.) -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.9 Features summary
On Tue, 30 Oct 2007 18:56:31 -0700, Gerhard Adam wrote: ...lots of setup by John and other good stuff by Adam snipped... > > ... But, in truth, I have never heard more >whining from people that have access to the best tools and technology >available, yet they can't seem to figure out how to code an IEBGENER job >stream. Even worse, there has never been more documentation available than >there is today, yet the average "programmer" doesn't seem to realize that >(just like books), PDFs don't read themselves. In the past many people were >accused of only copying the examples from manuals rather than reading them, >yet in many ways I wish the current crop would be even that industrious. I was incensed by this post - because I agreed so intensely with his sentiment. Now it is going to take me a few seconds longer to get some sleep tonight. >I also recognize that there are exceptions to this rant out there and to >them I apologize for my statements and wish them much luck. Yeah, me too. -- Tom Schmidt Madison, WI (Don't let my e-mail address fool you - I kept it for convenience; I'm a practicing sysprog at a z9 customer site) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADMINISTRIVIA: Announcement!
On Tue, 30 Oct 2007 14:15:42 -0500, Darren Evans-Young wrote: >I will be working for a company that helps companies migrate off of the >old IBM mainframe onto the much more current Microsoft .NET platform. >This will also help these companies utilize wasted space in empty office >buildings by filling these rooms with servers. This will in turn, reduce >energy consumption by channeling heat from the servers into the HVAC >system. So, a win-win solution for all involved. (no pun intended) Oh, I get it: You are moving on to the fast-paced career as a comedy writer! (Good time to be doing that, what with the Hollywood writer's strike looming.) Alternatively, with material like yours (above) you could maybe replace Dave Barry (since he, too, retired from his syndicate a few years ago). -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Slip Trap turning off GTF on different LPAR
On Mon, 29 Oct 2007 09:54:27 -0700, Edward Jaffe wrote: >Craddock, Chris wrote: >> /RO the_system_you_wanted,the_command_you_wanted? >> > >Are you suggesting enhancing SLIP to issue system commands? If so then it might also be a good idea to suggest that some single standard SAF UTOKEN value be used in order to anticipate/avoid potential confusion or documentation snafus that might otherwise result from that suggestion's initial implementation. (Just a thought; I liked the suggested enhancement but having the command trigger under any of a plethora of possible security environments may invite security failures.) -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IPL an LPAR with a very low weight?
On Fri, 26 Oct 2007 14:44:43 -0400, Dave Thorn wrote: >If an LPAR (in a "down" state) were set to a very low weight (1, for >instance) and then IPLed, would there be problems? > >This assumes that the other LPARs are not at high utilizations and using >all the CPU cycles themselves. > >Has anyone done this? Have problems occurred? Depends, of course. For starters the weight is relative to the aggregate for the CEC - if that is only, say, 2 (with 2 LPARs weighted at 1 each) you ought not expect to have any problems at all. Probably not your case though. Is your LPAR sharing any resources with any others? GRS or MIM come to mind here... if you need to "run" those on your resource challenged LPAR then you are a troublemaker. If your whimpy LPAR is a monplex, sharing nothing then no, it isn't a problem per se. More of an opportunity to catch up on your reading while you wait for it to respond. (We do it with a sandbox system and it is pretty pokey when the other LPARs are guzzling MIPS. Still, it all works but at an HO-scale. Just not the way to run a real railroad.) -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.8 Conditional Storage Obtain/Getmain Return Code
On Fri, 26 Oct 2007 13:22:42 -0400, Farley, Peter x23353 wrote: >I do realize they probably can't all be done at once, but IMHO it ought to >be a publicly stated IBM goal that all system interfaces *will* be >64-bit-clean no matter what amode they are invoked from. That's a really good idea but how about if we FIRST let IBM finish cleaning up after MVS/370 -> MVS/XA so we don't have below-the-16M-line issues that can throttle us? Then IBM can work out the above/below-the-bar issues along with your 64-bit- clean campaign. (Although I would MUCH rather see IBM bite the bullet and unleash us from the 3390 geometry tyranny. Though I'll probably sprout wings & fly before I see any more 3390 relief under z/OS, I suppose.) -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Wed, 24 Oct 2007 22:38:03 -0400, Binyamin Dissen wrote: > >What PCF did well was protect APF authorized CPs. > >You could not circumvent PCF unless you had the ability to write into an APF >library, which if you can - you can do whatever you want anyway. Oh yes I could (and did)! I could run any APF or non-APF command processor on the system where I had no write access to their APF libraries. That's why it was a joke. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 17:04:56 -0700, George Fogg wrote: >BTW, does the ISPF exits run authorized? I read the manual but not quite >sure if they do. George, It doesn't matter (much) whether the exits are authorized or not if all you do is issue a WTO to alert your automation package that it is safe (but not necessarily required) to issue the STOP command to the source TSO address space now. -- Tom Schmidt Madison, WI (The difference between authorized or not is whether or not the "+" prefixes the WTO in the display; you'll learn which right after the 1st WTO.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VARY too many devices offline
On Tue, 23 Oct 2007 19:48:11 -0500, Eric Bielefeld wrote: >I had a problem with IPLing I think a year behind the current date. This >was running under VM. VM was IPL'd with the wrong date, passing the date >along to each guest. ...snip... >The only problem after coming back up was that anyone >who had logged on TSO while the date was 1 year behind couldn't log on. >That was me, and a few of the programmers and the operator. Eric, Nobody died as a result of the operator error, right? ;) -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 17:53:05 -0500, Ed Gould wrote: >On Oct 23, 2007, at 3:17 PM, Tom Schmidt wrote: >>PCF was a joke as far as 'TSO security' was concerned. >> >> As long as you understood how TSO's command processors work and a >> quick understanding of PCF's working storage it can be a matter of >> minutes before you can build a working prototype to bypass PCF. (At least >> it was for me about 20 years ago.) I would not recommend it on that basis. >> >The issue is command control NOT anything else. If you had access to >the library then you could bypass all command checking by running the >the command under test library(asm) cp but we nave gave out access to >the library where commands where. But you are correct about dataset >security it was easily bypassable. In fact if you get access to where >the 2 byte security "key" was (read only protected storage) if I >remember correctly you could do anything. Its the same story with >RACF though if you are authorized you can bypass any security package. Ed, I well understood what PCF's goal was, but my point was that it was FAR too easy to circumvent the command 'control' portion. As long as you (or a friend) had program access to ANY library that you could execute from (without using TSO TEST) you could install your own command processor (same name, different purpose) that could then trivially circumvent PCF. There were other means of bypassing PCF, too, but I usually used that, my favorite mechanism. (Dance with the one that brought you.) -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 14:58:23 -0700, George Fogg wrote: >> I worked with a shop some years ago that had a similar requirement. For a >> certain class of user, management wanted this: >> >> 1. LOGON >> 2. Be placed immediately into ISPF >> 3. Exit ISPF >> 4. LOGOFF >> >> In other words, these users were not allowed to sit at Ready. Don't >> remember why. Doesn't matter. >> >> There turned out to be a simple solution. The 'moment' the user gets logged >> on and enters ISPF, issue this MVS command: P userid . It's not >> documented well (or maybe at all), but a TSO user in the 'stopping state' >> (my term), can continue the 'current operation' but will be logged off at >> the conclusion of that operation. ISPF is treated as one long continuous >> operation. The moment you exit ISPF, you are logged off. > >Skip: >Seems to work OK. >Now you need a bulletproof solution to force those users to be placed in ISPF >at logon and find a way to issue the "P userid" command. I think it can be >done in RACF's post-processing exit. George, That might be too early - under some odd timing conditions you might succeed (FSVO 'succeed') in logoff prior to ISPF (which would frustrate the end users and waste the company's resources... who's the bad guy then?) I would suggest pushing out an operator message in an ISPF initialization exit and letting automated operations issue the STOP command. That way you know the user was safely tucked into ISPF. I would also suggest that it should be mandatory that this 'feature' be verified & documented as an intended interface by IBM before using it. (I've used it in the dim past for a few things but none were particularly long-term. It worked for me, for example, when running a CLIST in a started task doing TSO RECEIVE (as in XMIT/RECEIVE) processing many years ago. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 14:40:40 -0400, Imbriale, Donald wrote: >The parm that you are passing could be a CLIST, constructed along these >lines: > >PROC 0 >do some allocates and stuff >start ISPF >LOGOFF > >As soon as the user leaves ISPF it should log them off If you are an applications programmer bent on actually doing your job (in spite of spiteful managers elsewhere): To defeat Don's mechanism you need to clear the TSO command stack prior to leaving ISPF. Read the TSO publications to find out how to do that. It isn't particularly hard and is a worthwhile exercise in programming by itself. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 14:20:10 -0500, Ed Gould wrote: >I do not know if IBM still sells it but at one time there was a >product called PCF. It was cheap IIRC and it worked quite well. I was >responsible for it for over 20 years and I never had an issue with >it. Just to give you an idea there is a table which has all TSO >commands in it and a "level" that you must have before the command >will be executed. The level is kept in UADS (or RACF IIRC). There is >also a table that restricts where a user can allocate new datasets. a >lot of the function of it has been doled out to other products (SMS >RACF etc) but I believe this product is a lot easier to implement and >you don't have to fool around with RACF to get a clean yes/no answer >to the question "am I allowed to do this command". > >BTW PCF = Program Control Facility PCF was a joke as far as 'TSO security' was concerned. As long as you understood how TSO's command processors work and a quick understanding of PCF's working storage it can be a matter of minutes before you can build a working prototype to bypass PCF. (At least it was for me about 20 years ago.) I would not recommend it on that basis. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tso racf
On Tue, 23 Oct 2007 13:20:59 -0400, Carroll, William wrote: >is there anyway to block or ignore or stop somebody from entering >a command on the command prompt through RACF, or anyother >method. This sounds more like a management problem than a technical problem. While you can sometimes address management problems by technical means, the overall satisfaction rate isn't as high as most folks might expect. Maybe it would help us help you if you could describe your problem a little better? -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to read source from a PDS member
John/OP: You might have overlooked an interesting gem of a feature of z/OS JCL: FREE=CLOSE. If you need to provide several alternative tables, you might be able to do so strictly in the enveloping JCL by doing something like this: //SYSLIB DD DISP=SHR,FREE=CLOSE,DSN=USERS.INPUT(TABLEX) //SYSLIB DD DISP=SHR,FREE=CLOSE,DSN=USERS.INPUT(TABLEY) //SYSLIB DD DISP=SHR,FREE=CLOSE,DSN=USERT.MUMBLE(TABLEZ) Note that the DDNAME is replicated three (3) times above, for example. For the cost of a full OPEN/GET/CLOSE you get to read the record from the first member and be positioned to the second member on your next OPEN/GET/CLOSE. Not high performance but pretty high function and very easy to maintain (just change the JCL). z/OS does not limit DDNAMES to a single appearance in a step (although you'd be surprised how many think otherwise). By crafty use of multiple DDs with identical names that resolve to different datasets (even to completely different data set names). Since any DD can use traditional data sets or PATH= it is also quite general. Nearly every high level language supports file opens and closes so nearly every high level language can perform this "trick". All you need to do is stop looping through the open/close once the open fails. (You ought to provide for error recovery if the open fails anyway so that might not be asking too much.) -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to read source from a PDS member
On Thu, 18 Oct 2007 18:24:12 -0500, Paul Gilmartin wrote: >On Thu, 18 Oct 2007 11:24:19 -0500, Tom Schmidt wrote: >> >>z/OS has the venerable OPEN-J service that might be what you are looking for >>here. Check the z/OS publications for the OPEN macro's TYPE=J operand. >> >Those fixated on performance will object to performing an OPEN >for each member rather than a single OPEN and multiple FINDs. OP did not state any performance requirements; he was interested only in alternatives to DYNALLOC. I provided him with one. Furthermore, OPEN-J has a different path length than traditional OPEN. Run a few benchmarks. I agree with you & others that BPAM is yet another possible alternative for OP to consider. Different strokes for different folks. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to read source from a PDS member
>On Thu, 18 Oct 2007 09:43:51 -0400, bit.listserv.ibm-main wrote: > >I need to read source code from a PDS member whose name I don't know >until my program runs, much the same as the COBOL >compiler handles "COPY memname" statements. Is dynalloc the only way to >go about it or does zOS provide a nice friendly >interface that lets me ask for source member data a line at a time? >Something comparable to VSE's LIBRM would be ideal. z/OS has the venerable OPEN-J service that might be what you are looking for here. Check the z/OS publications for the OPEN macro's TYPE=J operand. If you are looking from the perspective of a higher-level language such as C (although I might otherwise argue that point) then you can use BPXDYN service to switch both member name and dataset name. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Using IARVSERV across address spaces
On Tue, 16 Oct 2007 10:37:48 -0500, Roland Martin wrote: >I would like to use IARVSERV to share memory across address spaces but I >cannot find a sample or explanation on how to do so. The MVS Auth Assembler >Services Guide, chapter 16, figure 16-1 shows Addr Space A and Addr Space >B sharing data but the example in the chapter discusses sharing data within a >single address space. The description of IARVSERV in the reference manual >also does not shed any light. I've read through all the parameters and it is just >not jumping out at me how to specify a target address in a separate address >space. IARVSERV is documented in both the Authorized Assembler pubs and the generic (unauthorized) Assembler pubs. The examples in the Authorized pubs ought to, but do not, show interspace sharing. If I were you, I would submit an RCF. However, the generic/unauthorized Assembler Reference entry for IARVSERV has an example that comes close enough to what you need in Example 6. What Example 6 shows is how to share within an address space... but all you need to add is the source ALET and the target ALET in order to make the jump through the spaces. (The reason the example works within a single space is that the default ALET value (0) in both the source and target specifications; the primary space is just a special case that works well in their example.) -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LOAD a module into CSA/ECSA
On Mon, 8 Oct 2007 02:25:42 +0800, Johnny Luo wrote: >Actually took me some trouble to think of a way to accomplish this :) > >Reading directory of PDS/PDSE seems to be the solution, but it means a lot >of codes. > >LOAD it into jpa and then retrieve the info from CDE? Then I realized >that there is CSVQUERY. > >So my solution would be: > >1. First LOAD the module into JPA > >2. Retrieve the size of the module using CSVQUERY > >3. GETMAIN and do the real LOAD You are doing more work than you need to -- re-read the LOAD macro service documentation and pay more attention to what it returns in its registers. Specifically, pay attention to what it returns in register 0 and register 1 BUT ONLY IF register 15 has the expected/required return value. For example, your GETMAIN will need to be in the appropriate 31-bit/24-bit MODE (RMODE) and the hint for that is in the high-order bit of register 0. The GETMAIN length is derived from the low-order 3 bytes of register 1. (Be careful here: the length is DERIVED from the low-order 3 bytes -- you will need to do a little (simple) arithmetic AND pay attention to some special cases.) You only really need to use CSVQUERY if the low-order 3 bytes of register 1 are zero because the load module's length is greater than 16M, per the documentation. (And you might want to reconsider whether you really want that module loaded into dynamic ECSA if it is bigger than 16M... at least I would be more pensive under that condition.) -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dumping SMF directly to TAPE
On Sat, 6 Oct 2007 16:30:52 -0500, George Dranes wrote: >I have our SMF dump jobs dumping directly to a tape dataset with >LRECL=32760 and BLKKSIZE=32760,RECFM=VBS. Fortunately we are small >enough to dump SMF once a day so there are no speed issues not dumping to >DASD (saves a lot of dasd). I was just curious if this a a sound way of >handling SMF? I've even considered making the output tape blksize something >larger such as 256K but have always just stayed with the safe 32760. You mentioned that you dump directly to "a" tape dataset... isn't that putting an awful lot of faith and hope into one measely tape? I would, if I were doing that, be using 2 tapes written concurrently (just in case one of my tapes broke or otherwise failed). Call it "RAIT 0" (a la RAID 0) if you like. I would also be considering making the output tape blksize closer to 256K as you mentioned. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
