Re: Disappearing JES2 output
Oh well, I checked both type26 and type6 records. The jobname doesn't appear in the type6 records. The type26j2 records do show the jobname, but the fields printed out by sas look identical (other than convert/submit/ended/printed timestamps) for the batch 3 disappearing out of 20. The only difference in that batch is that the 3 disappearing ones are purged from another system than the 17 that arrive in ESF. And *these* two systems are different from the system where it executed. Which we already knew. My colleague also explained to me how this is supposed to work: ESF 'listens' to output for the printers it knows (in our case R720 among others) and reads it in using 'normal' services (because ESF does NOT run on the same system as the job generating output for that printer - on the same system some sort of intercept would get used). Once stuff arrived in ESF it checks if it is supposed to really print this outclass (to an IP printer located somewhere else). For class H, it doesn't. That output is supposed to stay in ESF spool. (well, *if* it ever arrived). My colleague also swears that in the case where he first noticed the disappearance, the output was still in JES spool (in a held class), and he manually changed that class to go to ESF. He *had* checked that something was in that output before changing the outclass. So we're still stumped :-( Did I miss an SMF record to look at? Best regards, Barbara -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Example of what a very small JCL Interpreter can do to your installation.
John Mattson wrote: > Somewhere between OS390 2.10 (our old system) and zos 1.08 (our > new system) the JCL interpreter changed. Funny you should notice that ... was wondering if anybody would. The change was first introduced in z/OS 1.8. It worked the old way in z/OS 1.7. When I first found this, I tested it all the way back to z/OS 1.4. > So, is this a "bug" or "working as designed"? IBM will have to say, unless someone can find something in the z/OS 1.8+ SRLs that describes this new behavior. The old behavior adheres to the rules of JCL in effect since OS/360 Release 13 MVT (where it was first possible to have multiple in-stream [DD *] data sets). But I have an opinion: it's a WAD, as I will attempt to demonstrate. Regardless, IT'S STILL DOCUMENTED TO WORK THE OLD WAY. Since it is hard for me to believe that this behavior is not intentional, you probably have as your only recourse a Readers' Comments form submission -- but all that will do is just get this new behavior documented. Note that page 12-14 of the "z/OS V1R9.0 MVS JCL Reference" SRL _still_ states: "To override more than one DD statement in a procedure, place the overriding DD statements in the same order as the overridden DD statements in the procedure." That is the OLD rule and behavior, not the NEW (as of z/OS 1.8). This behavior occurs even if you provide a //SYSIN DD * statement in front of the second in-stream data set. Doing so merely causes the statement that would be automatically generated had one not been provided NOT to be generated (obviously, as you would expect). So, the fact that you have a "missing" //SYSIN DD is not relevant, and does not affect its behavior. The results are identical. Thus, if you submit this JCL: //AFITJLMU JOB CLASS=S,MSGCLASS=X,TYPRUN=SCAN //UNVTEST PROC //PS001 EXEC PGM=IEFBR14 //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE //SYSINDD DISP=SHR,DSN=QALC.UNVLIB //MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB //SYSPRINT DD SYSOUT=* //PEND - //* //JS001 EXEC PROC=UNVTEST //MYSCRIPT DD * WHATEVER /* //SYSIN DD * WHEREEVER /* where the overriding DD statements [i.e., MYSCRIPT and SYSIN] are NOT "in the same order as the overridden DD statements in the procedure" then, starting with z/OS 1.8, both DD statements in the PROC _are_ overridden, despite the fact that they aren't explicitly [or implicitly] presented in the "same order." This is clearly an intentional change in behavior, and can only be explained as someone's unthinking idea of "how it should be working" I suspect. The fact that this behavior is not documented (even in the SRL for the next release after the behavior was first introduced) indicates to me that it was not thought to be of any importance. They probably actually thought they were doing us a big favor. But, wait! It's only going to get worse. Hang on to your hats, folks. I had some job streams where multiple in-stream data sets with the same DDname are defined (intentionally). So, I tested this with a few of those jobs. What the converter apparently does is to reach down into the JOB's JCL where it finds the first match on an overriding (it thinks!) DDname and then reorders the JCL to match that in the PROC! Yes, you read that right. I did not make that up. It reorders the input JCL! Programs that depend upon different or matching DDnames in the TIOT in a specific order will now be broken (but only if they are invoked using a "model" [so to speak] PROC). In-stream JCL that does not use a PROC apparently still works as before (no DD statements are reordered). But, I didn't want my existing "SYSIN" DD statement in the PROC to be overridden, WHICH IS WHY I PUT IT AFTER A DD STATEMENT THAT IS IN THE PROC AT THE END, SO THAT THE "NEW" DD STATEMENT IN THE INPUT STREAM WOULD GET _ADDED_ TO THE STEP'S JCL! (Apparently, whoever made this change did not read, nor understand, the distinction between OVERRIDING and ADDING JCL DD statements to a step in a PROC -- a concept that has been cast in concrete [at least until now] since 1965. So, IBM broke the old behavior. Normally, this would make me consider it to be a bug. But it can't possibly be a bug. Too much code had to be written to make it work like this. Thus, it must be a feature. In fact, further testing reveals that this behavior is general and ALL overriding DD statements in the instream JCL are just simply reordered to match those in the PROC. For example, if you submit this JCL: //UNVTEST PROC //PS001 EXEC PGM=IEFBR14 //FIRSTDD DD DISP=SHR,DSN=SYS1.LPALIB //REMOTE DD DISP=SHR,DSN=SYS1.PROCLIB //SYSINDD DISP=SHR,DSN=SYS1.PARMLIB //MYSCRIPT DD DISP=SHR,DSN=SYS1.LINKLIB //SYSPRINT DD SYSOUT=* //
Re: Disappearing JES2 output
Barbara Nitz wrote: > the 3 disappearing ones are purged from another system > than the 17 that arrive in ESF. Are those three perhaps running a different release of JES2? Are the JES2 INIT parameters "identical" for all members? -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Disappearing JES2 output
Barbara Nitz wrote: > the 3 disappearing ones are purged from another system > than the 17 that arrive in ESF. I still think it would be a good idea to define the output DD statement (for the data set whose output "disappears") so as to send it to multiple destinations, and resubmit all 20 (or whatever) JOBs, and take a look at the ones for which the output did not get processed properly. I understand that there was supposedly some data written by the program into that DDNAME for those JOBs [the JOBs that PURGED without that SYSOUT data set's contents being picked up by CA-SPOOL]. But, extraordinary claims require extraordinary proof. I'd demand to see the JOBs' output, and you can only do that for sure if you use an OUTPUT statement to "duplicate" the SYSOUT data set, where you will then be able to examine it (easily) using SDSF with no ambiguity. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Disappearing JES2 output
"Barbara Nitz" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Oh well, I checked both type26 and type6 records. The jobname doesn't appear in the type6 records. > > The type26j2 records do show the jobname, but the fields printed out by sas look identical (other than convert/submit/ended/printed timestamps) for the batch 3 disappearing out of 20. The only difference in that batch is that the 3 disappearing ones are purged from another system than the 17 that arrive in ESF. And *these* two systems are different from the system where it executed. Which we already knew. > > My colleague also explained to me how this is supposed to work: ESF 'listens' to output for the printers it knows (in our case R720 among others) and reads it in using 'normal' services (because ESF does NOT run on the same system as the job generating output for that printer - on the same system some sort of intercept would get used). Once stuff arrived in ESF it checks if it is supposed to really print this outclass (to an IP printer located somewhere else). For class H, it doesn't. That output is supposed to stay in ESF spool. (well, *if* it ever arrived). > > My colleague also swears that in the case where he first noticed the disappearance, the output was still in JES spool (in a held class), and he manually changed that class to go to ESF. He *had* checked that something was in that output before changing the outclass. > > So we're still stumped :-( > > Did I miss an SMF record to look at? > > Best regards, Barbara Just to throw a wild idea into the discussion: does the system where the output 'disappears' by any chance run another (test-) version of CA-SPOOL, which picks up the output, moves it to *its* database and purges it from JES spool? Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Disappearing JES2 output
Unfortunately the answer to basically all questions is NO: >Are those three perhaps running a different release of JES2? >Are the JES2 INIT parameters "identical" for all members? No, everything is at z/OS 1.8, all IPLing from the same deck in the same MAS. The init parms are not completely identical, of course (certain jobclasses only exist on certain MAS members and get assigned via commands, some exits only run on the system that has the actual connection to the outside world), but all JESs read the same physical data set for their initialization. >I still think it would be a good idea to define the output >DD statement (for the data set whose output "disappears") >so as to send it to multiple destinations, and resubmit >all 20 (or whatever) JOBs, and take a look at the ones >for which the output did not get processed properly. That was (kind of) vetoed by my colleague. He told me that the OUTPUT statement overrides the dd statement (whatever that means). We agreed that he will NOT send the joblog to the big basket anymore. I might suggest to add another step where he just copies the systsprt output into a held dataset (sysout=*). He wanted to change his rexx to *always and under any circumstance* produce output. >does the system where the >output 'disappears' by any chance run another (test-) version of >CA-SPOOL, which picks up the output, moves it to *its* database and >purges it from JES spool? Not that I know of. There is exactly one ESF in that sysplex/MAS (this is production). We *do* have RMS, which I understand once upon a time was also ESF, but it runs on the same system as ESF, which is not the one where the three *missing ones* were purged. *That* system only runs the newfangled stuff - websphere, java, wbifn But: Recently we started running a system called LDMS on that system. I have no clue how that is set up, but it is in a similar fashion reading the jes spool like all the others so. Best regards, Barbara -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer -- 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
recreating deleted dataset
Hi List. Does anybody have a utility or know how to recreate a deleted dataset (possibly by using the VTOC entry) Our storage administrator accidently deleted all the SMF dumped data from a system and it has major SCRT implications for workload usage. -- 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: Disappearing JES2 output
On Thu, 17 Jul 2008 11:19:46 +0200, Barbara Nitz <[EMAIL PROTECTED]> wrote: > >But: Recently we started running a system called LDMS on that system. I have no clue how that is set up, but it is in a similar fashion reading the jes spool like all the others so. > Barbara Now that would be my bet ( i am sure it starts being yours :-)) ) The product looks like an external writer extracting outputs from jes2 or jes3 . ( it seems it is written in Java ??? said google ) I would check if the archive in the product contains your missing output of check the LDMS logs ( hope there is some) . And last , (just because it has to be this) trace whatever is used to swallow the output ( dummy printer ? external writer? Fss SSI ? ) Good luck Bruno Sugliani zxnetconsult(at)free(dot)fr -- 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: Disappearing JES2 output - found it!
Kees, you made me look in the right direction!!! >does the system where the >output 'disappears' by any chance run another (test-) version of >CA-SPOOL, which picks up the output, moves it to *its* database and >purges it from JES spool? Well, it wasn't another CA-Spool, it was LDMS. Clear case of hysterically grown missing documentation who is allowed to use what output class... We found all missing output in LDMSs spool. That product doesn't write a message to syslog that it taken the output (too easy for problem determination). My colleague checked in the joblog of that STC, and there we found it. :-( Thanks to all who helped... Best regards, Barbara -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 -- 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: ALLOWUSERKEYCSA(NO)
While it is true that many might not care about someone corrupting a user key CSA area (even if it potentially compromises their system), that is not the only integrity exposure that user key CSA can result in. Allowing unauthorized communication between address spaces (i.e., "covert channels") is also made possible by this. By the way much of TSO/E is written to expect Key 8 callers. It always has been. If it was simply a question of changing one module to return in the key of the caller instead of the "known" key. So this is not necessarily a question of getting back in an unexpected state, it is also a question of not meeting the input requirements for a service.. If it were nicer, the service would have simply returned or abended. Instead it trusted its caller to have met those requirements. Are they documented? I have no idea. Peter Relson z/OS Core Technology Design -- 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: Clearing out DASD
Barry, But you can still find credit card numbers, names and addresses in the clear. A jigsaw puzzle is does not equal encryption. Same applies to compression. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Schwarz, Barry A > Sent: Tuesday, July 15, 2008 1:40 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: [IBM-MAIN] Clearing out DASD > > If your DASD does anything similar to the STK SVA 9500 I have, MVS > software becomes irrelevant. Every time a track is written to, the > hardware places the entire track's data in a new set of "sectors" on > some physical hard disk in the box. All this is done invisibly to MVS. > You basically never know where the physical write will go to and > therefore cannot tell if there are any sectors which have not been > over-written. Unless the DASD hardware comes with something akin to > "data destruct" with some kind of certification regarding how it is > implemented, you really cannot do a DOD acceptable clear. I doubt if > it > would satisfy HIPAA or SOX either. > > -Original Message- > From: Lizette Koehler [mailto:snip] > Sent: Tuesday, July 15, 2008 12:26 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Clearing out DASD > > I have a need to do a DOD type clearing of some dasd before it is > returned to the vendor. > > I found the CBT Tape entry (737) but was wondering if there is another > one out there that will write Binary 0's and 1's for the number of > times > I specify? I do not have DITTO. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HSM recall on one LPAR for request on another lpar
In a message dated 7/16/2008 6:29:53 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: >What is the risk? One possible risk is that the sandbox LPAR can crash while holding a reserve done by HSM, which then locks up some process on the prod LPAR. I crashed a "test" system once while it held a reserve on the JES2 checkpoint data set which caused the prod system's JES2 to get very unhappy. Bill Fairchild Rocket Software **Get the scoop on last night's hottest shows and the live music scene in your area - Check out TourTracker.com! (http://www.tourtracker.com?NCID=aolmus0005000112) -- 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: OUR FRIEND WEB IBMLINK is DOWN (AGAIN) - YES, I''M SHOCKED AND SURPRISED TOO
But I see no one making Titles - HSM SCREWED ME AGAIN. HOW SURPRISING!! I don't see ALL CAPS and extreme sarcasm for any other product. Must just be me. Sorry for raining on the parade. On Wed, Jul 16, 2008 at 6:28 PM, Ted MacNEIL <[EMAIL PROTECTED]> wrote: > >I can't understand why some people think that IBM-Main is the place to > >talk about the status of IBMLink. > > Because it's one of the most important tools out there? > And, we pay a lot of money for it? > > We b*tch and moan about other lousy services and software for the > mainframe, so why not the support tools? > - > Too busy driving to stop for gas! > > -- > 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 > > -- Mark Pace Mainline Information Systems -- 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: Example of what a very small JCL Interpreter can do to your installation.
On Wed, 16 Jul 2008 20:43:03 -0700, John Mattson <[EMAIL PROTECTED]> wrote: >There has been some talk about changing JCL interpretation. Sure >it is old, and ugly, but we are used to it, and it does "work". Here is >what happened going from os390 to zos 1.08 > >Somewhere between OS390 2.10 (our old system) and zos 1.08 (our >new system) the JCL interpreter changed. Here is a simplified example of >some JCL we have been running for years. >//AFITJLMU JOB CLASS=S,MSGCLASS=X,TYPRUN=SCAN >//UNVTEST PROC >//PS001 EXEC PGM=IEFBR14 >//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE >//SYSINDD DISP=SHR,DSN=QALC.UNVLIB >//MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB >//SYSPRINT DD SYSOUT=* >//PEND - >//* >//JS001 EXEC PROC=UNVTEST >//MYSCRIPT DD * > WHATEVER >/* > WHEREEVER >/* > Note the Extra "sysin" which the programmer left there in case he ever >needed it again, soft of "self documenting. Worked just fine... until zOS >1.08 > >Here is how OS390 2.10 handles the GENERATED SYSIN >//JS001 EXEC PROC=UNVTEST >++UNVTEST PROC >++PS001 EXEC PGM=IEFBR14 >++REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE >++SYSINDD DISP=SHR,DSN=QALC.UNVLIB >//MYSCRIPT DD * >+/MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB >++SYSPRINT DD SYSOUT=* >//SYSIN DD * GENERATED STATEMENT > > >Here is how zOS 1.08 handles the GENERATED SYSIN > >4 ++UNVTEST PROC >5 ++PS001 EXEC PGM=IEFBR14 >6 ++REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE >7 //SYSIN DD * GENERATED STATEMENT > +/SYSINDD DISP=SHR,DSN=QALC.UNVLIB >8 //MYSCRIPT DD * > +/MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB >9 ++SYSPRINT DD SYSOUT=* > >The os390 way, the JCL works. zOS 1.8 it gets the old "WHEREVER" >junk in the sysin dd and fails. Sigh. >Notice that zos 1.08 neatly lines up the sysin from way down at >the bottom with the existing SYSIN. Perfect example of a program being >"TOO HELPFUL". It wasn't broke, why did you "fix" it. >So, is this a "bug" or "working as designed"? Or maybe there is an >option somewhere that I can change and have it work the way it used to. >MUCH better than changing hundreds of pieces of JCL. Really. > APAR Identifier .. OA12842 Last Changed 08/06/10 PROC DD STMTS OVERRIDEN BY DD * INCORROUT CONTENTS OF FILES SWAPPED ( OA05951 ) Symptom .. IN INCORROUT Status ... CLOSED UR3 Severity ... 2 Date Closed . 06/04/13 Component .. 5752SC1B9 Duplicate of Reported Release . 709 Fixed Release 708 Component Name 5752 CNVRTR/INT Special Notice Current Target Date ..06/04/15 Flags SCP ... Platform Status Detail: APARCLOSURE - APAR is being closed. PE PTF List: PTF List: Release 708 : No PTF planned Release 709 : No PTF planned Release 720 : No PTF planned Release 730 : No PTF planned Parent APAR: Child APAR list: ERROR DESCRIPTION: When DD statements within a procedure are overridden with instream data (DD * or DD DATA), the data within the data sets represented by those input stream DD statements may be swapped (exchanged) if the overriding DDs are not in the correct order; that is, in the order in which the overridden stmts appear in the procedure. This can happen because the MVS Converter may reverse the sequence of two or more instream DD stmts with respect to each other, but the data within the files referenced by those DD stmts does not move along with the DD stmts themselves. Running the same JCL in R707, the out of sequence instream DD statements were simply ignored. This issue was previously reported in OA05951, which was closed SUG. Additional Symptoms: IEF655I INVALID DSNAME SPECIFIED WHEN SYSIN OR SYSOUT SPECIFIED (msgIEF655I) May occur if a SYSIN DD * statement is GENERATED and now properly finds and overrides a SYSIN DD DSN= statement. Additional Keywords: SYSIN reversed reversal, asterisk, instream -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Disappearing JES2 output
On Thu, 17 Jul 2008 07:11:42 +0200, Barbara Nitz <[EMAIL PROTECTED]> wrote: > In the past, we have had cases where the purge bit was mysteriously set for a TSO user (we never found out why or how, and IBM was also only shrugging their collective shoulders), which resulted in that TSO user not being able to xmit/receive anything anymore (that's how we found that out). I've run into the same thing a couple of times and never figured out the cause. I just log off and back on TSO to fix it. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IODF change causes next IPL to "hang"
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Jim Mulder > > IBM Mainframe Discussion List wrote on > 07/16/2008 04:35:28 PM: > > > Pat, in your situation try running the IPCS VERBEXIT BLSAIPST. > > The documented way of invoking that function is > > IPLDATA STATUS > > Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY A colleague asks, "When are the 'official' start and end times (events) that comprise 'IPL'?" >From the IPLDATA STATUS output it appears that 'official start' occurs after the IPLTEXT has been loaded and control transferred to it, and 'official end' occurs when *MASTER* has completed initialization. Is that pretty close? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: recreating deleted dataset
Ouch!! I don't know of anyway to recover that, maybe someone else does. I would think the VTOC entry would be gone, and it is highly likely that the data is already overwritten. How much did you lose? Was it more than one day's worth? You are required to have "% data collected" of >95% for the SCRT report to be accepted. 29 days of data out of 30 gives 96.67% and 30 days out of 31 gives 96.77% so if you don't lose anymore you should be alright. If you come up short maybe you could explain it as an exception in the SCRT report, and you could see if IBM will accept it. Tom Kelman Commerce Bank of Kansas City (816) 760-7632 > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Errol Van staden > Sent: Thursday, July 17, 2008 4:30 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: recreating deleted dataset > > Hi List. Does anybody have a utility or know how to recreate a deleted > dataset > (possibly by using the VTOC entry) Our storage administrator accidently > deleted all the SMF dumped data from a system and it has major SCRT > implications for workload usage. > > -- > 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 * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- 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: FTP Temporary File
Hello. I have tried with the quites also and is still giving the same problem Pls find the below jcl //FTP111 EXEC PGM=FTP,REGION=4096K //SYSPRINT DD SYSOUT=X //INPUT01 DD DSN=AADDXV.TEST.FILE1,DISP=OLD //SYSOUT DD SYSOUT=X //INPUTDD * FTP.T1V.U1TRI.COM LMCOE l12c03 LOCSITE FEFEIENDLY CD /MXS PUT '//DD:INPUT01' OUTPUT.FILE QUIT // The spool message shows the below EZA1460I Command: EZA1736I LOCSITE FWFRIENDLY EZA1460I Command: EZA1736I CD /MS8 EZA1701I >>> CWD /MS8 250 OK. Current directory is /MS8 EZA1460I Command: EZA1736I PUT '//DD:INPUT01' OUTPUT.FILE EZA2558W put fails: //DD:INPUT01 does not exist. EZA1460I Command: EZA1736I QUIT EZA1701I >>> QUIT 221-Goodbye. You uploaded 0 and downloaded 0 kbytes. 221 Logout. Could some one pls help me with this ?? Thanks, Rajeev -- 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: FTP Temporary File
Remove the quotes from around the //DD: on your put statement. I use this construct all the time and none of my jobs have quotes there. Jim Horne Systems Programmer Large Systems Engineering & Messaging IS7-5 Lowe's Companies, Inc. 401 Elkin Highway North Wilkesboro, NC 28659 336-658-4959 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Brain Sent: Thursday, July 17, 2008 9:14 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FTP Temporary File Hello. I have tried with the quites also and is still giving the same problem Pls find the below jcl //FTP111 EXEC PGM=FTP,REGION=4096K //SYSPRINT DD SYSOUT=X //INPUT01 DD DSN=AADDXV.TEST.FILE1,DISP=OLD //SYSOUT DD SYSOUT=X //INPUTDD * FTP.T1V.U1TRI.COM xx xx LOCSITE FEFEIENDLY CD /MXS PUT '//DD:INPUT01' OUTPUT.FILE QUIT // The spool message shows the below EZA1460I Command: EZA1736I LOCSITE FWFRIENDLY EZA1460I Command: EZA1736I CD /MS8 EZA1701I >>> CWD /MS8 250 OK. Current directory is /MS8 EZA1460I Command: EZA1736I PUT '//DD:INPUT01' OUTPUT.FILE EZA2558W put fails: //DD:INPUT01 does not exist. EZA1460I Command: EZA1736I QUIT EZA1701I >>> QUIT 221-Goodbye. You uploaded 0 and downloaded 0 kbytes. 221 Logout. Could some one pls help me with this ?? Thanks, Rajeev -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: recreating deleted dataset
> > Hi List. Does anybody have a utility or know how to recreate a deleted > dataset (possibly by using the VTOC entry) Our storage administrator accidently > deleted all the SMF dumped data from a system and it has major SCRT > implications for workload usage. > I have posted procedures for recovering a deleted dataset on this list before. It works only if the dataset is in one extent and the volume has not been overridden. You might also have to copy tracks to a non-SMS volume. I would be glad to help. You can contact me off-list. Jon Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: HSM recall on one LPAR for request on another lpar
John, I have 3 LPAR's participating in a HSMPlex. My 'batch' prod LPAR does all the HSM work (Migration, Backups, Recycles, Expirebv etc). The other 2 LPARs only allow Recalls and Recovers. No problems have been reported for the past 3 years with this setup. From: John Mattson [mailto:[EMAIL PROTECTED] Sent: Thu 7/17/2008 12:39 AM To: IBM-MAIN@BAMA.UA.EDU Subject: HSM recall on one LPAR for request on another lpar No sysplex, Each is a MONOPLEX, and GRS ring is active, all DASD shared. Anyone see any possible downside to having the sandbox lpar do RECALL's only? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Temporary File
On Thu, 17 Jul 2008 08:13:54 -0500, Brain <[EMAIL PROTECTED]> wrote: >Hello. > > >I have tried with the quites also and is still giving the same problem > >Pls find the below jcl > >//FTP111 EXEC PGM=FTP,REGION=4096K >//SYSPRINT DD SYSOUT=X >//INPUT01 DD DSN=AADDXV.TEST.FILE1,DISP=OLD >//SYSOUT DD SYSOUT=X >//INPUTDD * > FTP.T1V.U1TRI.COM > LMCOE > l12c03 > LOCSITE FEFEIENDLY > CD /MXS > PUT '//DD:INPUT01' OUTPUT.FILE > QUIT > // > >The spool message shows the below > >EZA1460I Command: >EZA1736I LOCSITE FWFRIENDLY >EZA1460I Command: >EZA1736I CD /MS8 >EZA1701I >>> CWD /MS8 >250 OK. Current directory is /MS8 >EZA1460I Command: >EZA1736I PUT '//DD:INPUT01' OUTPUT.FILE >EZA2558W put fails: //DD:INPUT01 does not exist. >EZA1460I Command: >EZA1736I QUIT >EZA1701I >>> QUIT >221-Goodbye. You uploaded 0 and downloaded 0 kbytes. >221 Logout. > > >Could some one pls help me with this ?? > No quotes around the //DD:ddname PUT //DD:INPUT01 OUTPUT.FILE -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ALLOWUSERKEYCSA(NO)
Why should you be concerned about key 8 CSA usage? Use of key 8 CSA by any code (installation or ISV) will eventually lead to an exploit of that code that will enable your users to upgrade their security authorization. This upgrade could mean becoming APF authorized or it could mean an upgrade of their security authority. Note the use of "will eventually" and not "may". A trivial example of an exploit is the corruption of the system. This type of exploit leaves evidence. The goal of the hacker is to upgrade authorities, obtain something they would not normally have access to (or update it) without any evidence of access/update. I refer to this as "good burglar". It is the "good burglar" exploits that you need to be worried about. You can argue that none of your users have the expertize to create such an exploit. You may be right. However, it only takes one person to develop an exploit and to publish said exploit. It takes a lot less expertize to implement an exploit once you have the script. You do have people that can implement the exploit. Lots of them! Anyone involved with securing a company's assets needs to be concerned about mainframe software, both the installation/implementation and its integrity. IBM has an option available as part of the IPL parameters (ALLOWUSERKEYCSA()) that will disable a known feature, that if enabled, will allow for an exploit to be developed. Make sure you have documented reasons for allowing key 8 CSA as the business risk is high. Ray Overby Peter Relson wrote: While it is true that many might not care about someone corrupting a user key CSA area (even if it potentially compromises their system), that is not the only integrity exposure that user key CSA can result in. Allowing unauthorized communication between address spaces (i.e., "covert channels") is also made possible by this. By the way much of TSO/E is written to expect Key 8 callers. It always has been. If it was simply a question of changing one module to return in the key of the caller instead of the "known" key. So this is not necessarily a question of getting back in an unexpected state, it is also a question of not meeting the input requirements for a service.. If it were nicer, the service would have simply returned or abended. Instead it trusted its caller to have met those requirements. Are they documented? I have no idea. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Example of what a very small JCL Interpreter can do to your installation.
How on earth can IBM make a change as significant as this and not even document the change in behavior? I can imagine this affecting many job streams with negative consequences. >>> Mark Zelden <[EMAIL PROTECTED]> 7/17/2008 8:54 AM >>> APAR Identifier .. OA12842 Last Changed 08/06/10 PROC DD STMTS OVERRIDEN BY DD * INCORROUT CONTENTS OF FILES SWAPPED ( OA05951 ) Symptom .. IN INCORROUT Status ... CLOSED UR3 Severity ... 2 Date Closed . 06/04/13 Component .. 5752SC1B9 Duplicate of Reported Release . 709 Fixed Release 708 Component Name 5752 CNVRTR/INT Special Notice Current Target Date ..06/04/15 Flags SCP ... Platform Status Detail: APARCLOSURE - APAR is being closed. PE PTF List: PTF List: Release 708 : No PTF planned Release 709 : No PTF planned Release 720 : No PTF planned Release 730 : No PTF planned Parent APAR: Child APAR list: ERROR DESCRIPTION: When DD statements within a procedure are overridden with instream data (DD * or DD DATA), the data within the data sets represented by those input stream DD statements may be swapped (exchanged) if the overriding DDs are not in the correct order; that is, in the order in which the overridden stmts appear in the procedure. This can happen because the MVS Converter may reverse the sequence of two or more instream DD stmts with respect to each other, but the data within the files referenced by those DD stmts does not move along with the DD stmts themselves. Running the same JCL in R707, the out of sequence instream DD statements were simply ignored. This issue was previously reported in OA05951, which was closed SUG. Additional Symptoms: IEF655I INVALID DSNAME SPECIFIED WHEN SYSIN OR SYSOUT SPECIFIED (msgIEF655I) May occur if a SYSIN DD * statement is GENERATED and now properly finds and overrides a SYSIN DD DSN= statement. Additional Keywords: SYSIN reversed reversal, asterisk, instream -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Note that my email domain has changed from jo-annstores.com to joann.com. Please update your address book and other records to reflect this change. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Example of what a very small JCL Interpreter can do to your installation.
On Thu, 17 Jul 2008 10:37:50 -0400, Scott Rowe <[EMAIL PROTECTED]> wrote: >How on earth can IBM make a change as significant as this and not even document the change in behavior? I can imagine this affecting many job streams with negative consequences. > > May occur if a SYSIN DD * statement is GENERATED and now > properly finds and overrides a SYSIN DD DSN= statement. > Perhaps because they used MAY occur Could be my english , but i would have expected something like "will occur" it is a bit difficult to document a "may be" just wondering Bruno Sugliani zxnetconsult(at)free(dot)fr -- 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: Disappearing JES2 output
To me, all this (to include the mysterious purge bit) points to something outside of JES. AS we gaze around looking for things that interface to JES, we see a common denominator. I'd assume the issue is with CA-SPOOL. Or perhaps a local exit. Or perhaps an unrelated product that also interfaces with JES. Of course, continued research into JES logs and trails may help isolate the culprit. But, for the moment, I'd put JES aside as a suspect. The test scenario suggests that CA-SPOOL is getting a little confused, perhaps thinking that it had already processed a given output. I would like to see another test, this time everything being unique. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Barbara Nitz Sent: Thursday, July 17, 2008 12:12 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Disappearing JES2 output >These days it's called CA-Spool. See? I said I'm not a printer person! :-) (I have no clue how to *access* that thing, either!) >Did the 'missing' output ever really exist? Perhaps the application >opened the file but never actually wrote anything. I guess I didn't make it very clear that my colleague submitted the *same* job about 20 times *at the same time* to test. He even used the same jobname for it. Sometimes the systsprt made it into ESF, in 3 of 20 cases it did not, but sometimes all 20 cases arrived correctly. In and of itself, the job works, you can see the output (some status display for some network resource) in SDSF. >What are the (default) characteristics of SYSOUT CLASS H? >Anything special, or different than whatever the MSGCLASS >of the JOB is? $HASP842 OUTCLASS(H) OUTPUT=PRINT,BLNKTRNC=YES, $HASP842 OUTDISP=(WRITE,WRITE),TRKCELL=YES The default class (X) had outdisp=(hold,hold). My colleague has changed the default class for his testing to Z (the big waste paper basket): HASP842 OUTCLASS(Z) OUTPUT=DUMMY,BLNKTRNC=YES, HASP842 OUTDISP=(WRITE,WRITE),TRKCELL=NO It occured with both X and Z, but in no way predictably. >Is the output that does NOT disappear also SPOOLed to >SYSOUT CLASS H? Is that (non-disappearing) output also >DESTed to R720? Not sure I understand the question. He told me that he *saw* the output via SDSF (I assume that means it was spooled in JES), but it never made it to ESF. It was just purged from the spool. The output that made it into ESF was later purged (presumably because ESF set the purge bit). From what little I know about this, ESF will do the printing to R720 if instructed to do so. So far the only thing common to all the disappearing output (that we could see) was that it was purged from another system than all the others. I had hoped to avoid looking at SMF records, because the jobnames are all the same, and I will have to look at about 200 of those same jobs. Guess it's time to get out a little SAS program. What worries me is that this started happening after a maintenance refresh to this sysplex (1.8). In the past, we have had cases where the purge bit was mysteriously set for a TSO user (we never found out why or how, and IBM was also only shrugging their collective shoulders), which resulted in that TSO user not being able to xmit/receive anything anymore (that's how we found that out). Unfortunately, by the time we know which output is missing we cannot check the status of the output anymore because it is already gone. :-( I'll let y'all know if we find anything. Best regards, Barbara -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Disaster in the making
This gives me pause. What were the original "site selectors" thinking ?? Gary Green wrote: We plan and plan and plan to make sure everything is correct with the systems and such that we are responsible for. Then along comes someone that make a decision that makes it all moot. You gotta read this article. If it were not so serious, it would be funny. http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9109498&source=NLT_DIS&nlid=14 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Terminal SYSIN in TSO Logon Proc
What is SYSIN TERM=TS used for in a TSO logon proc? What could happen if it is freed? If one needs to use it for a utility, should it be allocated back to term when finished? -- 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: Terminal SYSIN in TSO Logon Proc
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Lindy Mayfield > Sent: Thursday, July 17, 2008 10:36 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Terminal SYSIN in TSO Logon Proc > > What is SYSIN TERM=TS used for in a TSO logon proc? What could happen > if it is freed? It assigns the DD name SYSIN to the user's TSO terminal. Similar to ALLOC DDN(SYSIN) DSN(*). Freeing will only affect program which tries to OPEN the SYSIN dd name. > > > > If one needs to use it for a utility, should it be allocated back to > term when finished? TSO itself does not use SYSIN for anything. Most TSO commands don't use it. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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: Disaster in the making
Low Bid. Many government entities are bound by law to solicit proposals from everyone and take the lowest bid. I once worked in the construction industry, and 'low bid' was used as a derogatory term and as a general answer to the question: 'What went wrong?'. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Thursday, July 17, 2008 10:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Disaster in the making This gives me pause. What were the original "site selectors" thinking ?? Gary Green wrote: >We plan and plan and plan to make sure everything is correct with the systems and such that we are responsible for. Then along comes someone that make a decision that makes it all moot. > >You gotta read this article. If it were not so serious, it would be funny. > >http://www.computerworld.com/action/article.do?command=viewArticleBasic &articleId=9109498&source=NLT_DIS&nlid=14 > NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Temporary File
This worked with or without the quotes on the input file. Step01 creates a file with my name contact and date. //TECGRM01 JOB 5740TC,G.MANSELL,MSGCLASS=O,PRTY=9,CLASS=A, //NOTIFY=&SYSUID TYPRUN=SCAN //STEP01EXEC PGM=UTIL0008 //SYSUT1DD DISP=SHR,DSN=UMBTEST.CTLCDLIB(TECGRM00) //SYSUDUMP DD SYSOUT=* //SYSUT2DD DSN=&&TESTCON, // DISP=(,PASS,DELETE), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=0), // UNIT=(SYSSCR,2),SPACE=(TRK,(2,2)) //STEP02 EXEC PGM=FTP, // PARM='SYS093.UMB.COM (EXIT TRACE' //* Umb3 //SYSUT2DD DSN=&&TESTCON,DISP=(OLD,PASS) //NETRCDD DUMMY //OUTPUT DD SYSOUT=* //INPUTDD * ** PUT '//DD:SYSUT2''TES.CONNECT.DIRECT.COPY' QUIT /* On Thu, 17 Jul 2008 08:13:54 -0500, Brain <[EMAIL PROTECTED]> wrote: >Hello. > > >I have tried with the quites also and is still giving the same problem > >Pls find the below jcl > >//FTP111 EXEC PGM=FTP,REGION=4096K >//SYSPRINT DD SYSOUT=X >//INPUT01 DD DSN=AADDXV.TEST.FILE1,DISP=OLD >//SYSOUT DD SYSOUT=X >//INPUTDD * > FTP.T1V.U1TRI.COM > LMCOE > l12c03 > LOCSITE FEFEIENDLY > CD /MXS > PUT '//DD:INPUT01' OUTPUT.FILE > QUIT > // > >The spool message shows the below > >EZA1460I Command: >EZA1736I LOCSITE FWFRIENDLY >EZA1460I Command: >EZA1736I CD /MS8 >EZA1701I >>> CWD /MS8 >250 OK. Current directory is /MS8 >EZA1460I Command: >EZA1736I PUT '//DD:INPUT01' OUTPUT.FILE >EZA2558W put fails: //DD:INPUT01 does not exist. >EZA1460I Command: >EZA1736I QUIT >EZA1701I >>> QUIT >221-Goodbye. You uploaded 0 and downloaded 0 kbytes. >221 Logout. > > >Could some one pls help me with this ?? > No quotes around the //DD:ddname PUT //DD:INPUT01 OUTPUT.FILE -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. Thank you. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Disaster in the making
As a guess, the land was probably donated by the city of Nashville, or sold for very little. I would hate to think what was under that data center. If the data center is 21 years old, the landfill is a lot older. When did some of the recent EPA regs on landfills start impacting municiple owned landfills? Larry Gray Large Systems Engineering Lowe's Companies 336-658-7944 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Thursday, July 17, 2008 11:45 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Disaster in the making Low Bid. Many government entities are bound by law to solicit proposals from everyone and take the lowest bid. I once worked in the construction industry, and 'low bid' was used as a derogatory term and as a general answer to the question: 'What went wrong?'. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Thursday, July 17, 2008 10:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Disaster in the making This gives me pause. What were the original "site selectors" thinking ?? Gary Green wrote: >We plan and plan and plan to make sure everything is correct with the systems and such that we are responsible for. Then along comes someone that make a decision that makes it all moot. > >You gotta read this article. If it were not so serious, it would be funny. > >http://www.computerworld.com/action/article.do?command=viewArticleBasic &articleId=9109498&source=NLT_DIS&nlid=14 > NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- 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: Disaster in the making
On 17 Jul 2008 08:05:28 -0700, [EMAIL PROTECTED] (Rick Fochtman) wrote: >This gives me pause. What were the original "site selectors" thinking ?? Sometimes it isn't what one is thinking - but what one isn't thinking that matters most. -- 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: Terminal SYSIN in TSO Logon Proc
I think its SYSTSIN Itschak | Itschak Mugzach | Director | SecuriTeam Software | | Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: Itschak Mugzach | Web: www.Securiteam.co.il | -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Thursday, July 17, 2008 5:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Terminal SYSIN in TSO Logon Proc > -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Lindy Mayfield > Sent: Thursday, July 17, 2008 10:36 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Terminal SYSIN in TSO Logon Proc > > What is SYSIN TERM=TS used for in a TSO logon proc? What could happen > if it is freed? It assigns the DD name SYSIN to the user's TSO terminal. Similar to ALLOC DDN(SYSIN) DSN(*). Freeing will only affect program which tries to OPEN the SYSIN dd name. > > > > If one needs to use it for a utility, should it be allocated back to > term when finished? TSO itself does not use SYSIN for anything. Most TSO commands don't use it. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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 __ NOD32 3276 (20080717) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Disaster in the making
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman > > This gives me pause. What were the original "site selectors" > thinking ?? Since it's a government entity, it could have been any (combination of) these, and not necessarily in this order: 1. Cheapest available; 2. "Pork-barrel"; 3. political favor; 4. political disfavor. > > Gary Green wrote: > > >We plan and plan and plan to make sure everything is correct > with the systems and such that we are responsible for. Then > along comes someone that make a decision that makes it all moot. > > > >You gotta read this article. If it were not so serious, it > would be funny. > > > >http://www.computerworld.com/action/article.do?command=viewAr > ticleBasic > >&articleId=9109498&source=NLT_DIS&nlid=14 -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HSM recall on one LPAR for request on another lpar
On Wed, 16 Jul 2008 23:29:24 +, Ted MacNEIL wrote: >>I only run HSM on my prod LPAR because I do not want to risk sharing HSM data >>with my sandbox. > >What is the risk? Are they in the same SYSPLEX? > In our case, not risk, but inaccessibility of drives. >>So occasionally during testing on LPAR:TEST I have >to recall something, and of course, it fails since there is no HSM on that >LPAR. So I go over to the Prod LPAR, recall the DS, go back to TEST and >REPLY CONTINUE, and I get another HSM message. Even tho the data set is now >recalled, I have to cancel and restart the job. Is there a way around >this? > Me, too. This ought to be APARable. Of course it's WAD, but it's a bad design. There's a clear objective that's not being met. There's a similar problem when allocation asks me to select an offline unit from among a list when all other suitable units are busy. I know that no offline unit is suitable (they're offline for a reason). So I wait until another job completes and frees a unit. But the allocation WTO won't accept that unit; it insists on one from the list it presented earlier. The environment changes, quite dynamically, but in these two cases the logic driving the WTO is impaired by a static tunnel vision. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Terminal SYSIN in TSO Logon Proc
2008/7/17 Itschak Mugzach <[EMAIL PROTECTED]>: > I think its SYSTSIN No - that's something quite different. SYSTSIN is used when running the Terminal Monitor Program in batch (or in any non-terminal environment). The TMP reads command input from SYSTSIN in that case, but it is unrelated to SYSIN. Tony H. >> What is SYSIN TERM=TS used for in a TSO logon proc? What could happen >> if it is freed? > > It assigns the DD name SYSIN to the user's TSO terminal. Similar to ALLOC > DDN(SYSIN) DSN(*). Freeing will only affect program which tries to OPEN the > SYSIN dd name. -- 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: HSM recall on one LPAR for request on another lpar
Having a sysplex member with no access to tape drives is a perfect environment for HSM Common Recall Queue, where some other member(s) perform ML2 recalls on behalf of other systems. We generally run the Common Queue everywhere just to spread the work among members. But we recently built a new sysplex member that did not have tape for a few weeks. In the meantime, recalls were performed by other members in a perfectly seamless manner. As a TSO user, for example, you would never know that a data set was actually being recalled by another system. Same messages, just as fast. You do have to have a parallel sysplex for a shared CF structure. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [EMAIL PROTECTED] Paul Gilmartin <[EMAIL PROTECTED] .COM> To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List <[EMAIL PROTECTED] Subject .EDU> Re: HSM recall on one LPAR for request on another lpar 07/17/2008 10:21 AM Please respond to IBM Mainframe Discussion List <[EMAIL PROTECTED] .EDU> On Wed, 16 Jul 2008 23:29:24 +, Ted MacNEIL wrote: >>I only run HSM on my prod LPAR because I do not want to risk sharing HSM data with my sandbox. > >What is the risk? Are they in the same SYSPLEX? > In our case, not risk, but inaccessibility of drives. >>So occasionally during testing on LPAR:TEST I have >to recall something, and of course, it fails since there is no HSM on that LPAR. So I go over to the Prod LPAR, recall the DS, go back to TEST and >REPLY CONTINUE, and I get another HSM message. Even tho the data set is now recalled, I have to cancel and restart the job. Is there a way around >this? > Me, too. This ought to be APARable. Of course it's WAD, but it's a bad design. There's a clear objective that's not being met. There's a similar problem when allocation asks me to select an offline unit from among a list when all other suitable units are busy. I know that no offline unit is suitable (they're offline for a reason). So I wait until another job completes and frees a unit. But the allocation WTO won't accept that unit; it insists on one from the list it presented earlier. The environment changes, quite dynamically, but in these two cases the logic driving the WTO is impaired by a static tunnel vision. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMF TYPE 60 REPORTS
Several of our data sets (GDGs) have mysteriously disappeared. If I am correct, doesn't SMF TYPE 60 records track data set deletion by userid? Does anyone know of a tool that can generate a report using those type SMF records? thanks, JEllis -- 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: Disaster in the making
On 17 Jul 2008 10:21:32 -0700, [EMAIL PROTECTED] (Chase, John) wrote: >Since it's a government entity, it could have been any (combination of) >these, and not necessarily in this order: > >1. Cheapest available; >2. "Pork-barrel"; >3. political favor; >4. political disfavor. Or "It's someone else's job to check for the site for construction suitability". -- 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: SMF TYPE 60 REPORTS
In a message dated 7/17/2008 1:11:26 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: Does anyone know of a tool that can generate a report using those type SMF records?>> Micheal Cleary's DAF(dataset audit facility) available at _www.cbttape.org_ (http://www.cbttape.org) looks at all combinations 14/15/60's, 80's(Racf). Well worth the effort. **Get the scoop on last night's hottest shows and the live music scene in your area - Check out TourTracker.com! (http://www.tourtracker.com?NCID=aolmus0005000112) -- 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: SMF TYPE 60 REPORTS
I can't recommend more highly: Michael Cleary's DAF program, downloadable from the CBTTAPE site. Wunnerful, wunnerful stuff. Judy Ellis wrote: Several of our data sets (GDGs) have mysteriously disappeared. If I am correct, doesn't SMF TYPE 60 records track data set deletion by userid? Does anyone know of a tool that can generate a report using those type SMF records? thanks, JEllis -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF TYPE 60 REPORTS
thanks everyone for your input. I will look for DAF program. JEllis -- 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: Example of what a very small JCL Interpreter can do to your installation.
I guess this shouldn't have changed for the sake of backass compatibility. But, I've always been bothered (and debugged application JCL) when overrides didn't match the order in procs (and the messages there were almost non-existent). Folks relying in //SYSIN DD * GENERATED STATEMENT are getting what they deserve. :) -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruno Sugliani Sent: Thursday, July 17, 2008 7:46 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Example of what a very small JCL Interpreter can do to your installation. On Thu, 17 Jul 2008 10:37:50 -0400, Scott Rowe <[EMAIL PROTECTED]> wrote: >How on earth can IBM make a change as significant as this and not even document the change in behavior? I can imagine this affecting many job streams with negative consequences. > > May occur if a SYSIN DD * statement is GENERATED and now > properly finds and overrides a SYSIN DD DSN= statement. > Perhaps because they used MAY occur Could be my english , but i would have expected something like "will occur" it is a bit difficult to document a "may be" just wondering Bruno Sugliani zxnetconsult(at)free(dot)fr -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF TYPE 60 REPORTS
DAF is great. I used to use it myself from time to time. I have one concern though. It seems to use a lot of CPU time. I know when I was at my last full time job, it seemed to practically bury the MP3000-H50 processor. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: "Rick Fochtman" <[EMAIL PROTECTED]> I can't recommend more highly: Michael Cleary's DAF program, downloadable from the CBTTAPE site. Wunnerful, wunnerful stuff. -- 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
TLMS ALOG
Has anyone ever restored a TLMS ALOG file from tape? I've not found it in the CA manuals. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Terminal SYSIN in TSO Logon Proc
Thanks, but that's something different. SYSTSIN is used for sure by TSO. (Well, TSO batch anyway). I'm sure that SYSIN is used by some utilities. Whether they are "standard" or not, I'm not sure. I can't think of any offhand. I mean, I can think of utilities that use SYSIN of course, but I can't think of any that expect SYSIN to be allocated for terminal input. This would be a moot point if there wasn't at least one sentence about it in the TSO documentation. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b480/3.2.3.2 Not a whole sentence, but a half sentence that says, "... and specify that SYSIN and SYSPRINT are to be directed to the user's terminal." Then there is an example TSO logon proc with those in it. If not for that I would think that it might just be some sort of convention to allocate SYSIN to terminal. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Itschak Mugzach Sent: 17. heinäkuuta 2008 20:20 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Terminal SYSIN in TSO Logon Proc I think its SYSTSIN Itschak | Itschak Mugzach | Director | SecuriTeam Software | | Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: Itschak Mugzach | Web: www.Securiteam.co.il | -- 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: SMF TYPE 60 REPORTS
-- DAF is great. I used to use it myself from time to time. I have one concern though. It seems to use a lot of CPU time. I know when I was at my last full time job, it seemed to practically bury the MP3000-H50 processor. -- It doesn't have that effect on bigger iron, Eric. And the CPU time that it uses is a small price to pay for the wealth of information it can provide. :-)) -- 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: Terminal SYSIN in TSO Logon Proc
Lindy Mayfield wrote: This would be a moot point if there wasn't at least one sentence about it in the TSO documentation. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b480/3.2.3.2 Not a whole sentence, but a half sentence that says, "... and specify that SYSIN and SYSPRINT are to be directed to the user's terminal." Then there is an example TSO logon proc with those in it. If not for that I would think that it might just be some sort of convention to allocate SYSIN to terminal. SYSIN and SYSPRINT are not used by TSO. I have never seen them coded in a TSO logon procedure. However, doing so harms nothing. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Terminal SYSIN in TSO Logon Proc
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Thursday, July 17, 2008 2:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Terminal SYSIN in TSO Logon Proc SYSIN and SYSPRINT are not used by TSO. I have never seen them coded in a TSO logon procedure. However, doing so harms nothing. I have seen them so coded (way back when). Probably on an old system running TCAM. Meanwhile, they CAN BE used by CLIST and REXX when invoking programs. Does that constitute TSO (in CLIST case)? But this is an old thing going way back to when SPF was just a dream (and ISPF wasn't even a gleam in anyone's eye). And so, if you decide to invoke a utility, such as IEBGENER, within your CLIST code, you will need to point SYSIN and SYSPRINT to somewhere other than the terminal. Then when the utility has finished, point them back to the terminal. Regards, Steve.T -- 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: SMF TYPE 60 REPORTS
If all you want is who scratched a non-VSAM data set. look at the SMF type 17 record. -- 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: Terminal SYSIN in TSO Logon Proc
Lindy, I looked in the link you supplied. I was surprised to see the syslib card more then the sysprint & sysin. (//SYSLIBDD DSN=SYS1.MACLIB,DISP=SHR-) it look like they prepared this procedure for running online assembly. Itschak | Itschak Mugzach | Director | SecuriTeam Software | | Email: [EMAIL PROTECTED] | Mob: +972 522 986404 | Skype: Itschak Mugzach | Web: www.Securiteam.co.il | -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Thursday, July 17, 2008 9:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Terminal SYSIN in TSO Logon Proc Lindy Mayfield wrote: > This would be a moot point if there wasn't at least one sentence about it in the TSO documentation. > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ikj4b480/3. > 2.3.2 > > Not a whole sentence, but a half sentence that says, "... and specify that SYSIN and SYSPRINT are to be directed to the user's terminal." Then there is an example TSO logon proc with those in it. > > If not for that I would think that it might just be some sort of convention to allocate SYSIN to terminal. > SYSIN and SYSPRINT are not used by TSO. I have never seen them coded in a TSO logon procedure. However, doing so harms nothing. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html __ NOD32 3276 (20080717) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Example of what a very small JCL Interpreter can do to your installation.
I'm confused. Are you saying that APAR OA12842 broke it? or that it fixed it? It looks to me like they fixed a problem. It says The solution for this APAR has been shipped in the base code of z/OS 1.8 (HBB7730), JES2 1.8 (HJE7730) and JES3 1.8 (HJS7730). If I understood the original poster, he has //AFITJLMU JOB CLASS=S,MSGCLASS=X,TYPRUN=SCAN //UNVTEST PROC //PS001 EXEC PGM=IEFBR14 //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE //SYSINDD DISP=SHR,DSN=QALC.UNVLIB //MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB //SYSPRINT DD SYSOUT=* //PEND - //* //JS001 EXEC PROC=UNVTEST //MYSCRIPT DD * WHATEVER /* WHEREEVER /* and the WHEREEVER causes a system generated //SYSIN which overrides his original //SYSINDD DISP=SHR,DSN=QALC.UNVLIB I also like to leave junk at the bottom of my JCL members as notes. But I always have a // hard end of job card before the junk at the bottom so I never see this problem. Roger Bolan infoprint.com Boulder, Colorado, USA P Think before you print IBM Mainframe Discussion List wrote on 07/17/2008 08:37:50 AM: > How on earth can IBM make a change as significant as this and not > even document the change in behavior? I can imagine this affecting > many job streams with negative consequences. > > >>> Mark Zelden <[EMAIL PROTECTED]> 7/17/2008 8:54 AM >>> > APAR Identifier .. OA12842 Last Changed 08/06/10 > PROC DD STMTS OVERRIDEN BY DD * INCORROUT CONTENTS OF FILES > SWAPPED ( OA05951 ) > > Symptom .. IN INCORROUT Status ... CLOSED UR3 > Severity ... 2 Date Closed . 06/04/13 > Component .. 5752SC1B9 Duplicate of > Reported Release . 709 Fixed Release 708 > Component Name 5752 CNVRTR/INT Special Notice > Current Target Date ..06/04/15 Flags > SCP ... > Platform > > Status Detail: APARCLOSURE - APAR is being closed. > > PE PTF List: > > PTF List: > Release 708 : No PTF planned > Release 709 : No PTF planned > Release 720 : No PTF planned > Release 730 : No PTF planned > > Parent APAR: > Child APAR list: > > > ERROR DESCRIPTION: >When DD statements within a procedure are overridden with > instream data (DD * or DD DATA), the data within the data sets > represented by those input stream DD statements may be swapped > (exchanged) if the overriding DDs are not in the correct order; > that is, in the order in which the overridden stmts appear in > the procedure. >This can happen because the MVS Converter may reverse the > sequence of two or more instream DD stmts with respect to each > other, but the data within the files referenced by those DD > stmts does not move along with the DD stmts themselves. >Running the same JCL in R707, the out of sequence instream > DD statements were simply ignored. > >This issue was previously reported in OA05951, which was > closed SUG. > > Additional Symptoms: >IEF655I INVALID DSNAME SPECIFIED WHEN SYSIN OR SYSOUT >SPECIFIED (msgIEF655I) > May occur if a SYSIN DD * statement is GENERATED and now > properly finds and overrides a SYSIN DD DSN= statement. > > Additional Keywords: >SYSIN reversed reversal, asterisk, instream > > > > > -- > Mark Zelden > Sr. Software and Systems Architect - z/OS Team Lead > Zurich North America / Farmers Insurance Group - ZFUS G-ITO > mailto:[EMAIL PROTECTED] > z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ > Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html > > > Note that my email domain has changed from jo-annstores.com to > joann.com. Please update your address book and other records to > reflect this change. > > CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission > contains confidential and privileged information intended only for > the addressee. If you are not the intended recipient, please be > advised that you have received this material in error and that any > forwarding, copying, printing, distribution, use or disclosure of > the material is strictly prohibited. If you have received this > material in error, please (i) do not read it, (ii) reply to the > sender that you received the message in error, and (iii) erase or > destroy the material. Emails are not secure and can be intercepted, > amended, lost or destroyed, or contain viruses. You are deemed to > have accepted these risks if you communicate with us by email. Thank you. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -
Re: ALLOWUSERKEYCSA(NO)
On Thu, 17 Jul 2008 07:17:01 -0400, Peter Relson <[EMAIL PROTECTED]> wrote: ... >Allowing unauthorized communication between address spaces (i.e., "covert >channels") is also made possible by this. Unauthorized communication? Give me a break, there must be a thousand other ways for address spaces to communicate. One example, ENQ and GQSCAN with the "message" contained in the RNAME. -- 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: OUR FRIEND WEB IBMLINK is DOWN (AGAIN)
Perhaps when we see them trading something that is up quite a bit for something that is down quite a bit I think anyone who is concerned with availability would be saying to themselves the following: 1. shouldn't they be focused on fixing the availability issues with said new wonder product? 2. if they can't get them fixed (which it appears not) then shouldn't they be getting rid of the product that has more availability problems? Let's see, which one would our customers like more, the product that is up and available, or the product that is down and unavailable?. Thinking, thinking. I don't see ALL CAPS and extreme sarcasm for any other product. Must just be me. Sorry for raining on the parade. -- 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: Example of what a very small JCL Interpreter can do to your installation.
The confusing issue was begun a very long time ago. If there is apparent input data with no specific DD statement to match it up with, there was a SYSIN dd statement generated above it. Until recently, that extraneous SYSIN dd statement had no effect on the JCL except to prevent either a JCL error or an "invalid jcl" error as this SYSIN was ignored since it was out of sequence (in most cases) with the specification of SYSIN (if there was one) in the procedure. Now with OA12842, (and I have seen other similar changes) the JCL specified outside of the procedure (mostly for override purposes) does not have to be in the same sequence as the JCL in the procedure. The overriding JCL statements will now be matched up irregardless of the sequence. APAR OA12842 is fixing the problem where the input data is not moved along with the matching overriding JCL statement, especially in the case of multiple sets of input data. This is where the original poster encountered the problem. The internally generated SYSIN dd statement has now been matched up with the SYSIN dd statement in the procedure, and the input data following this generated statement was moved along with it.This is where the original poster encountered the problem. WAD/BAD? Depends on whether the end results are what makes you happy. To me you were doing something that was puzzling at the least. Now you are being forced to follow what was an assumed correct way of doing JCL coding. On Thu, 17 Jul 2008 13:44:52 -0600, Roger Bolan <[EMAIL PROTECTED]> wrote: >I'm confused. Are you saying that APAR OA12842 broke it? or that it fixed >it? It looks to me like they fixed a problem. >It says >The solution for this APAR has been shipped in the base code of >z/OS 1.8 (HBB7730), JES2 1.8 (HJE7730) and JES3 1.8 (HJS7730). > >If I understood the original poster, he has >//AFITJLMU JOB CLASS=S,MSGCLASS=X,TYPRUN=SCAN >//UNVTEST PROC >//PS001 EXEC PGM=IEFBR14 >//REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE >//SYSINDD DISP=SHR,DSN=QALC.UNVLIB >//MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB >//SYSPRINT DD SYSOUT=* >//PEND - >//* >//JS001 EXEC PROC=UNVTEST >//MYSCRIPT DD * > WHATEVER >/* > WHEREEVER >/* > >and the WHEREEVER causes a system generated //SYSIN which overrides his >original >//SYSINDD DISP=SHR,DSN=QALC.UNVLIB > >I also like to leave junk at the bottom of my JCL members as notes. But I >always have a // hard end of job card before the junk at the bottom so I >never see this problem. > >Roger Bolan >infoprint.com > >Boulder, Colorado, USA > > >P Think before you print > >IBM Mainframe Discussion List wrote on 07/17/2008 >08:37:50 AM: > >> How on earth can IBM make a change as significant as this and not >> even document the change in behavior? I can imagine this affecting >> many job streams with negative consequences. >> >> >>> Mark Zelden <[EMAIL PROTECTED]> 7/17/2008 8:54 AM >>> >> APAR Identifier .. OA12842 Last Changed 08/06/10 >> PROC DD STMTS OVERRIDEN BY DD * INCORROUT CONTENTS OF FILES >> SWAPPED ( OA05951 ) >> >> Symptom .. IN INCORROUT Status ... CLOSED UR3 >> Severity ... 2 Date Closed . 06/04/13 >> Component .. 5752SC1B9 Duplicate of >> Reported Release . 709 Fixed Release 708 >> Component Name 5752 CNVRTR/INT Special Notice >> Current Target Date ..06/04/15 Flags >> SCP ... >> Platform >> >> Status Detail: APARCLOSURE - APAR is being closed. >> >> PE PTF List: >> >> PTF List: >> Release 708 : No PTF planned >> Release 709 : No PTF planned >> Release 720 : No PTF planned >> Release 730 : No PTF planned >> >> Parent APAR: >> Child APAR list: >> >> >> ERROR DESCRIPTION: >>When DD statements within a procedure are overridden with >> instream data (DD * or DD DATA), the data within the data sets >> represented by those input stream DD statements may be swapped >> (exchanged) if the overriding DDs are not in the correct order; >> that is, in the order in which the overridden stmts appear in >> the procedure. >>This can happen because the MVS Converter may reverse the >> sequence of two or more instream DD stmts with respect to each >> other, but the data within the files referenced by those DD >> stmts does not move along with the DD stmts themselves. >>Running the same JCL in R707, the out of sequence instream >> DD statements were simply ignored. >> >>This issue was previously reported in OA05951, which was >> closed SUG. >> >> Additional Symptoms: >>IEF655I INVALID DSNAME SPECIFIED WHEN SYSIN OR SYSOUT >>SPECIFIED (msgIEF655I) >> May occur if a SYSIN DD * statement is GENERATED and now >> properly finds and overrides a SYSIN DD DSN= statement. >> >> Additional Keywords: >>SYSIN reversed reversal, asterisk, i
Re: OUR FRIEND WEB IBMLINK is DOWN (AGAIN)
I sure don't see what that has to do with ALL CAPS and sarcasm. But to your points. 1 - Do you know that they are not? I'll give IBM the benefit of the doubt here. 2 - I'm willing to bet any amount of money that IBMLink is up more often than it is down. On Thu, Jul 17, 2008 at 4:24 PM, Bobbie Justice <[EMAIL PROTECTED]> wrote: > Perhaps when we see them trading something that is up quite a bit for > something that is down quite a bit I think anyone who is concerned with > availability would be saying to themselves the following: > > 1. shouldn't they be focused on fixing the availability issues with said > new wonder product? > > 2. if they can't get them fixed (which it appears not) then shouldn't they > be getting rid of the product that has more availability problems? > > Let's see, which one would our customers like more, the product that is up > and available, or the product that is down and unavailable?. Thinking, > thinking. > > >> I don't see ALL CAPS and extreme sarcasm for any other product. >> >> Must just be me. Sorry for raining on the parade. >> >> > -- > 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 > > -- Mark Pace Mainline Information Systems -- 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: OUR FRIEND WEB IBMLINK is DOWN (AGAIN)
In a message dated 7/17/2008 4:01:40 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: 2 - I'm willing to bet any amount of money that IBMLink is up more often than it is down. >> That's bogus enough for me? It's just hard to maintain five nine systems with one eight tools. Sam's response was pretty much on the mark. What's bad is IT'S BEEN GOING ON FOR SO LONG. Most of the places we work would cast us out on the streets if our systems were this awful and had this poor availability. **Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr000520) -- 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: SMF TYPE 60 REPORTS
>DAF is great. I used to use it myself from time to time. I have one concern >though. It seems to use a lot of CPU time. I know when I was at my last full >time job, it seemed to practically bury the MP3000-H50 processor. That's a small processor. Besides, if your priorities (goals) are set properly, it shouldn't matter. - Too busy driving to stop for gas! -- 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: OUR FRIEND WEB IBMLINK is DOWN (AGAIN)
>2 - I'm willing to bet any amount of money that IBMLink is up more often than >it is down. Possibly, but the 'when' is critical. The downs (unscheduled) seem to be when most 9-5'rs want/need it. And, others (scheduled) seem to be on weekends, when new releases are being implemented (when problems are more likely to occur). - Too busy driving to stop for gas! -- 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: OUR FRIEND WEB IBMLINK is DOWN (AGAIN)
That's bogus enough for me? It's just hard to maintain five nine systems with one eight tools. Sam's response was pretty much on the mark. What's bad is IT'S BEEN GOING ON FOR SO LONG. Most of the places we work would cast us > out on the streets if our systems were this awful and had this poor availability. exactly, very well put.. Most of us wouldn't have a job if our systems were down as much as web ibmlink. -- 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
State of IDAHO feedback
Hi, We had so much bad IT press from some State IT departments lately, so I decided to share this piece of information : EPICS Replacement Project - Department of Health and Welfare Executive Summary The project leadership of Ryan Fullmer and Randy Ashton in the Eligibility Program Integrated Computer Systems (EPICS) Replacement Project is deserving of recognition on the basis of project design, unique and productive methodology, and contribution to significant improvements in service delivery to Idaho citizens, even prior to the project’s completion. Project Description: The EPICS Replacement (ER) Project is a three year project in the Department of Health and Welfare to replace the existing 22 year old mainframe-based automated system used for welfare program eligibility determinations, and to modernize business processes to improve accuracy, timeliness, and consistency of welfare service delivery statewide. The three-year project was initially funded for one year with $5 million by the 2006 Idaho legislature for State Fiscal Year 2007. The legislature provided additional funding in 2007 and 2008 to fund the project through SFY 2009 (for a project total of just under $28 million). The project is just completing its second year. Significance to Government Operation: The ER Project is significant for Idaho because of its design, methodology, and achievement: The Project Managers have created an integrated project design, connecting business processes to software development and operational needs with iterative project deliverables. Fundamental to this design was the realization that changes in business culture were equal or greater challenges than the hardware replacement or software function. The project’s sponsorship is shared between the Division of Welfare and the Division of Information Technology. The project’s methodology is fairly unique in government and many are surprised that it is working. The ER Project uses Agile Development to provide iterative development on specific products or releases, using self-directed teams to create high-value business functionality. Work is done collaboratively and completed according to business value. The Project also uses the Lean Office methodology to eliminate waste in processes, thereby maximizing efficiency of staff, reducing costs, and improving performance. Finally, the Project shares business and technology decisions on the Department’s Intranet, providing transparency to tasks, schedules, summaries, standards, and decisions. The Project’s ability to provide interim deliverables means real improvements to service delivery have already occurred. For example, within seven months of the Project’s start date a significant improvement was made when real-time eligibility for Food Stamps was implemented. Periodic improvements have continued and have resulted in more timely service delivery, better program performance, and greater capacity to match our ever increasing workload. Benefits to Idaho Citizens: The ER Project has delivered tangible improvements for Idahoans. This includes decreasing the time from application to eligibility decision, less costly service delivery (fewer taxes) as increased caseloads have been managed without increased staff and services delivered more consistently statewide. Operational Benefits: The ER Project has delivered tools and processes that have created improved accuracy in all welfare benefit programs. It has increased capacity for workers to process applications and maintain cases. Previously unavailable data became easily accessible, enhancing our ability to effectively manage statewide operations. Better data and more consistent operations have created more effective welfare service delivery. http://www2.state.id.us/itrmc/events/achievementawards/2008awardswinners. htm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IBM's 2Q2008 Earnings
I haven't listened to IBM's earnings conference call yet (in which there
might be more nuggets of information), but the CFO's prepared remarks are
quite interesting:
http://www.ibm.com/investor/2q08/presentation/2q08prepared.pdf
Here are the facts I pulled out of the prepared remarks:
1. System z (hardware) revenue was up 32 percent for the quarter (year over
year); capacity ("MIPS") grew 34 percent. That means System z gained
marketshare again. It also means customers keep getting lower average
per-MIPS pricing, especially for most non-U.S. dollar buyers. (That's just
simple math.)
And it also means any of you among these buyers are very roughly 34 percent
more productive. That is, typically you're managing 34 percent more
transactions and business volume with the same number of (talented) staff.
Is there anybody else in IT -- or indeed, probably any other industry --
that can pull off that sort of productivity gain? Not too many.
Maybe ask your boss for half that, which would be a 17 percent raise. :-)
2. Loughridge said, "...frankly, we were sold out." Apparently IBM built
System z machines as fast as it could in the quarter, and it still wasn't
enough to satisfy demand.
3. System z demand was particularly strong in Europe and the Americas, and
in the financial sector. As you know the U.S. financial sector, in
particular, is facing hard times with the mortgage market problems. But it
appears that these companies are targeting investment only into the most
fruitful areas, and System z is one of the very few. (See above regarding
productivity.)
4. IBM shipped a record number of System z specialty engines in the
quarter, indicating strong demand for placing new applications on the
mainframe.
5. In June, IBM sold its first mainframe ever in Vietnam, to a financial
institution. Vietnam's economy is small but growing very rapidly.
6. I also see in the earnings that there's continuing movement toward the
most highly virtualized servers, and I think businesses are doing that for
entirely sensible and compelling reasons. It's blades, mid- and high-end
System p (which now includes System i), and System z that are performing
best -- and z is a standout in that group. So this is something to look at
in your own organization, particularly if you see movement in the other
direction to de-consolidate, de-virtualize, de-centralize, or as one of my
colleagues says, dis-integrate your shared infrastructure. In the
virtualization hierarchy the System z, as we all know, is the most highly
virtualized by far. So maybe somebody needs to come up with a
"virtualization quotient," a measurement that indicates just how
virtualized you are. If you're increasing your VQ, outstanding, but if it's
flat or decreasing, that could be a sign of trouble in many ways.
I don't speak for IBM, but I'll say anyway: thank you all again for another
outstanding performance. There just aren't enough superlatives, really, and
I know we IBMers very much appreciate it. Now, anybody here speak
Vietnamese? :-)
- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM's 2Q2008 Earnings
>1. System z (hardware) revenue was up 32 percent for the quarter (year over
>year); capacity ("MIPS") grew 34 percent. That means System z gained
marketshare again.
You CANNOT say that, as a completely accurate statement!
You need to know how many new customers those MIPS were sold to.
If the increased capacity went to existing companies, then there is NO increase
in share.
-
Too busy driving to stop for gas!
--
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: Example of what a very small JCL Interpreter can do to your installation.
Dave Gibney wrote: > Folks relying in //SYSIN DD * GENERATED STATEMENT are getting > what they deserve. :) You didn't read everything I wrote. This has nothing to do with the automatically-generated //SYSIN DD * statement. Explicit DD statements are being reordered. What is happening happens long after (and despite) any automatically-generated DD statements. -- WB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: State of IDAHO feedback
Maybe I just missed it, but when I read the article, I couldn't see exactly what new hardware or operating system they were using now or before. They did mention "22 year old mainframe-based ..." for the old system. Did they migrate to a new mainframe and new application software? Or something else? Roger Bolan infoprint.com Boulder, Colorado, USA P Think before you print Anton Britz <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 07/17/2008 04:21 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject State of IDAHO feedback Hi, We had so much bad IT press from some State IT departments lately, so I decided to share this piece of information : EPICS Replacement Project - Department of Health and Welfare Executive Summary The project leadership of Ryan Fullmer and Randy Ashton in the Eligibility Program Integrated Computer Systems (EPICS) Replacement Project is deserving of recognition on the basis of project design, unique and productive methodology, and contribution to significant improvements in service delivery to Idaho citizens, even prior to the project’s completion. Project Description: The EPICS Replacement (ER) Project is a three year project in the Department of Health and Welfare to replace the existing 22 year old mainframe-based automated system used for welfare program eligibility determinations, and to modernize business processes to improve accuracy, timeliness, and consistency of welfare service delivery statewide. The three-year project was initially funded for one year with $5 million by the 2006 Idaho legislature for State Fiscal Year 2007. The legislature provided additional funding in 2007 and 2008 to fund the project through SFY 2009 (for a project total of just under $28 million). The project is just completing its second year. Significance to Government Operation: The ER Project is significant for Idaho because of its design, methodology, and achievement: The Project Managers have created an integrated project design, connecting business processes to software development and operational needs with iterative project deliverables. Fundamental to this design was the realization that changes in business culture were equal or greater challenges than the hardware replacement or software function. The project’s sponsorship is shared between the Division of Welfare and the Division of Information Technology. The project’s methodology is fairly unique in government and many are surprised that it is working. The ER Project uses Agile Development to provide iterative development on specific products or releases, using self-directed teams to create high-value business functionality. Work is done collaboratively and completed according to business value. The Project also uses the Lean Office methodology to eliminate waste in processes, thereby maximizing efficiency of staff, reducing costs, and improving performance. Finally, the Project shares business and technology decisions on the Department’s Intranet, providing transparency to tasks, schedules, summaries, standards, and decisions. The Project’s ability to provide interim deliverables means real improvements to service delivery have already occurred. For example, within seven months of the Project’s start date a significant improvement was made when real-time eligibility for Food Stamps was implemented. Periodic improvements have continued and have resulted in more timely service delivery, better program performance, and greater capacity to match our ever increasing workload. Benefits to Idaho Citizens: The ER Project has delivered tangible improvements for Idahoans. This includes decreasing the time from application to eligibility decision, less costly service delivery (fewer taxes) as increased caseloads have been managed without increased staff and services delivered more consistently statewide. Operational Benefits: The ER Project has delivered tools and processes that have created improved accuracy in all welfare benefit programs. It has increased capacity for workers to process applications and maintain cases. Previously unavailable data became easily accessible, enhancing our ability to effectively manage statewide operations. Better data and more consistent operations have created more effective welfare service delivery. http://www2.state.id.us/itrmc/events/achievementawards/2008awardswinners. htm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Re: IBM's 2Q2008 Earnings
Ted MacNeil writes (>) in reply to me (>>):
>>1. System z (hardware) revenue was up 32 percent
>>for the quarter (year over year); capacity ("MIPS")
>>grew 34 percent. That means System z gained
>>marketshare again.
>You CANNOT say that, as a completely accurate statement!
>You need to know how many new customers those MIPS were
>sold to. If the increased capacity went to existing
>companies, then there is NO increase in share.
Actually IBM's CFO said that (gained marketshare), so I'm just repeating
what he said.
Now, presumably the CFO looks at revenue, what Wall Street, IT market
analysts, and other CFOs look at, too. I can understand why. :-) So one
would assume he means revenue share. That is, you take the total server
market, count it in dollars (sales), and allocate shares among various
vendors and types of servers.
There's also unit marketshare, that is you take the total number of
physical machines and then allocate share percentages to each vendor and by
each type, ignoring the price for each machine. Unit marketshare is fairly
easy to count, but I think it's becoming increasingly less meaningful with
virtualization (if it were ever terribly meaningful). And you can have big
debates about how to count: for example, do you count blade racks, blade
chassis, blade cards, blade CPU sockets, or blade cores?
But I don't think you're talking about unit marketshare either. What you're
talking about I think is percentage of companies (and governments) running
(and/or buying) IBM mainframes. That's something like "market penetration"
or a certain form of "installed base." One big reason an IBM-MAIN reader
might care about that metric is it might be a proxy for professional
employment stability (whether you might switch employers more or less
frequently).
There's very little information in the earnings report on that score, but
you can logically conclude two things:
1. It is significantly more difficult to increase revenue at such high
rates if at the same time the percentage of companies/governments running
your product decreases or even stays flat. That's just simple mathematics,
just like 34 percent more MIPS at 32 percent higher revenues means a lower
average price per MIPS.
2. There was at least one new mainframe customer in 2Q2008: a financial
institution in Vietnam. In fact, that was a brand new *country* for the
mainframe, and thus it easily rose to the level that a CFO would mention.
I happen to know that wasn't the only new mainframe customer last quarter,
but that wasn't in the earnings report (individually; of course the revenue
is counted).
Market penetration has measurement problems also. For example, if you're
doing well in an industry that is busy merging, reducing the number of
separate companies in that industry, did your market penetration decline?
Most rational people would say no, but the mathematics (uncorrected) might
say yes. And there are other ways to measure market penetration besides
number of companies. For example, you might measure it in percentage of
banking transactions (in the banking industry) or some other measurement of
business activity. When you get those data, they're really interesting. But
it's often tough to figure out that information.
- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM's 2Q2008 Earnings
>Market penetration has measurement problems also. Exactly! So, that's why you cannot make those kind of global statements! - Too busy driving to stop for gas! -- 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
DFHSM: setsys exportesds(cimode)
Hello, Has anyone ever seen/used this option " SETSYS EXPORTESDS(CIMODE) " in the Dfhsm Arccmdxx Starter Set. I have done a search to no-avail. Hopefully someone can let me know if this option is still being used or NOT and can tell me where I can find the information. -- 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: Example of what a very small JCL Interpreter can do to your installation.
On Thu, 17 Jul 2008 02:21:29 -0500, William H. Blair wrote: > >But, 42 years of experience with IBM tells me that this is how >it is going to be, so I'm going to have to find some other way >of "hiding" in-stream data sets. (You're not the only one to >use this technique. It's not unheard of. I've seen it in many >"production" JCL streams. Other folks are going to get burned >by this, but I have no clue how many. I would hope not many.) > I have long been in the habit of using: //HIDDEN DD * (text to be ignored) All the unprocessed text that I want. I think this makes my intent far more clear than relying on your convention of using an undeclared SYSIN as a collateral comment. I consider the latter irresponsibly lazy and lacking in referential transparency. It's redolent of trying to assure one's job security by writing incomprehensible code. >I wonder if anybody at IBM even thought about the possibility >that this slick new feature might break existing customer JCL. >Probably not. They probably got an award just for their bright >idea. Oh, well. > Whine, whine, whine! JCL has sucked for those 42 years. This has frequently been attributed in this forum to resource constraints in those early systems. Now advancing technology has relieved those constraints and IBM is DTRT in making JCL infinitesimally closer to what it should have been from the beginning. Hooray! It's similar to USERKEYCSA -- some things that have to be fixed should be fixed. I'd be glad to see more changes for robustness and clear reporting of user errors. E.g.: o Duplicate DDNAMEs within a step should be treated as a JCL error. (I understand JES3 already does this.) This itself would have blocked the pitfall described in this thread. o The "SYSIN DD * GENERATED STATEMENT" behavior should be removed from the language. The last time I encountered this, I had inadvertently left a '/' off a JCL statement (perhaps a comment) before my actual intended SYSIN. The utility then saw an empty SYSIN. Took me far too long to spot. At least there should be an option such as GENSYSIN(YES|NO) on the JOB statement. I'd use NO. o All the usages described in the JCL manual as having "unpredictable" effects should be reported as JCL errors (or those with repeatable behaviors documented). Perhaps a conversion utility should be provided to tidy up legacy careless JCL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM's 2Q2008 Earnings
Ted MacNeil writes: >>Market penetration has measurement problems also. >Exactly! >So, that's why you cannot make those kind of global >statements! Ted, what can I tell you? IBM's CFO said IBM System z gained marketshare. Now, while his prepared remarks include both GAAP and non-GAAP statements -- and you should read the whole thing for all the details, including the SEC filing -- unless you've got some information that says he's wrong, I don't know what point you're trying to make. The quarterly financial results for any publicly traded company, including IBM, get reported to the U.S. Securities and Exchange Commission, the Internal Revenue Service (for tax purposes), and are scrutinized by independent auditors. There's a whole legal and regulatory framework for how this stuff gets reported, accurately. Revenue gets counted and counted well. And since IBM (and others) have a really good estimate of total server revenue in the global market, yes, the CFO can (and did) make that kind of "global statement." But I don't speak for IBM. The CFO and a few others do. You can read what he said. Thank you again, all, for your continuing and growing business. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ALLOWUSERKEYCSA(NO) was (Re: CA Jobtrac 3.5 Off Support)
It is real fun to send dumps to vendors who have used Key 8 CSA to store
programs
I have used Omegamon MVS classic to get a list of such storage areas
then via TASID option 7, gone to that area in storage, and then overlayed the
area with nulls ('00'x). The resulting abends are good to send to vendors.
This was done in our sandbox just to prove the point, that is was REAL EASY
to break their code, and suggest the possibility it could break other stuff.
Regards
Bruce Hewson
--
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: State of IDAHO feedback
I think every buzz word on that new fangled project management stuff is in there. This is such bull.Can't they just say we made the process more efficient, and eliminated waste? No, too simple... And probably not the case. Inertia is pretty strong Anton Britz wrote: Hi, We had so much bad IT press from some State IT departments lately, so I decided to share this piece of information : EPICS Replacement Project - Department of Health and Welfare Executive Summary The project leadership of Ryan Fullmer and Randy Ashton in the Eligibility Program Integrated Computer Systems (EPICS) Replacement Project is deserving of recognition on the basis of project design, unique and productive methodology, and contribution to significant improvements in service delivery to Idaho citizens, even prior to the project’s completion. Project Description: The EPICS Replacement (ER) Project is a three year project in the Department of Health and Welfare to replace the existing 22 year old mainframe-based automated system used for welfare program eligibility determinations, and to modernize business processes to improve accuracy, timeliness, and consistency of welfare service delivery statewide. The three-year project was initially funded for one year with $5 million by the 2006 Idaho legislature for State Fiscal Year 2007. The legislature provided additional funding in 2007 and 2008 to fund the project through SFY 2009 (for a project total of just under $28 million). The project is just completing its second year. Significance to Government Operation: The ER Project is significant for Idaho because of its design, methodology, and achievement: The Project Managers have created an integrated project design, connecting business processes to software development and operational needs with iterative project deliverables. Fundamental to this design was the realization that changes in business culture were equal or greater challenges than the hardware replacement or software function. The project’s sponsorship is shared between the Division of Welfare and the Division of Information Technology. The project’s methodology is fairly unique in government and many are surprised that it is working. The ER Project uses Agile Development to provide iterative development on specific products or releases, using self-directed teams to create high-value business functionality. Work is done collaboratively and completed according to business value. The Project also uses the Lean Office methodology to eliminate waste in processes, thereby maximizing efficiency of staff, reducing costs, and improving performance. Finally, the Project shares business and technology decisions on the Department’s Intranet, providing transparency to tasks, schedules, summaries, standards, and decisions. The Project’s ability to provide interim deliverables means real improvements to service delivery have already occurred. For example, within seven months of the Project’s start date a significant improvement was made when real-time eligibility for Food Stamps was implemented. Periodic improvements have continued and have resulted in more timely service delivery, better program performance, and greater capacity to match our ever increasing workload. Benefits to Idaho Citizens: The ER Project has delivered tangible improvements for Idahoans. This includes decreasing the time from application to eligibility decision, less costly service delivery (fewer taxes) as increased caseloads have been managed without increased staff and services delivered more consistently statewide. Operational Benefits: The ER Project has delivered tools and processes that have created improved accuracy in all welfare benefit programs. It has increased capacity for workers to process applications and maintain cases. Previously unavailable data became easily accessible, enhancing our ability to effectively manage statewide operations. Better data and more consistent operations have created more effective welfare service delivery. http://www2.state.id.us/itrmc/events/achievementawards/2008awardswinners. htm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- 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: State of IDAHO feedback
In a message dated 7/17/2008 10:01:44 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: efficient, and eliminated waste? No, too simple... And probably not the case. Inertia is pretty strong >> Well you get to fill out your bingo buzzword card and look for the lights to shine brighter around Boise..22yrs is just ridiculous! **Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr000520) -- 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's 2Q2008 Earnings
Sorry, I missed an important nuance in what IBM's CFO said. Here's what I wrote (directly out of the prepared remarks): >4. IBM shipped a record number of System z specialty engines in the >quarter, indicating strong demand for placing new applications on the >mainframe. That's *number* of engines (zAAPs, zIIPs, IFLs). And that's a really important distinction because each System z10 EC engine has much more capacity than, say, a z990 or z9 engine. Thus the strong demand to run new mainframe application workloads is that much greater when you look at the real capacity. OK, back to regularly scheduled programming. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM's 2Q2008 Earnings
In a message dated 7/17/2008 11:45:18 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: That's *number* of engines (zAAPs, zIIPs, IFLs). And that's a really important distinction because each System z10 EC engine has much more capacity than, say, a z990 or z9 engine. Thus the strong demand to run new mainframe application workloads is that much greater when you look at the real capacity. >> I read thru the thing at _http://www.ibm.com/investor/2q08/_ (http://www.ibm.com/investor/2q08/) and it looked like a lot of consolidation back to the mainframe-most likely z/VM and z/Linux. Especially if you look at decline in i-System on p.21. **Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr000520) -- 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: IODF change causes next IPL to "hang"
IBM Mainframe Discussion List wrote on 07/17/2008 09:00:16 AM: > A colleague asks, "When are the 'official' start and end times (events) > that comprise 'IPL'?" > > From the IPLDATA STATUS output it appears that 'official start' occurs > after the IPLTEXT has been loaded and control transferred to it, and > 'official end' occurs when *MASTER* has completed initialization. > > Is that pretty close? The data collection for IPLDATA STATUS was just a little thing I hacked together in OS/390 1.3 to help me find a starting point of where to look when I got asked to help diagnose "why did that IPL take so long?" problems. It presents things in four phases IPL-NIP-IEEVIPL-IEEMB860 because that happens to be how the system initialization code is structured. But I was not trying to create any 'official' terminolgy. From an internal code point of view, IPL ends when NIP starts. From a customer point of view, IPL more likely is considered to have ended when the system is ready to run applications - after the network is up, the database is up, and the applications are up. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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
ALLOWUSERKEYCSA(NO)
___ Note: This e-mail is subject to the disclaimer contained at the bottom of this message. ___ Personally, I'm with Mark Zelden on this, especially as we are upgrading to z/OS 1.9 with ALLOWUSERKEYCSA(YES) mainly because of 2 IBM products: Tivoli Identity Manager & Omegamon/IMS. Fix what you can, when you can. Stephen Hall Mainframe Platform Manager Platform Support Services Technology Services INSURANCE AUSTRALIA GROUP (IAG) ___ The information transmitted in this message and its attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of the sender. This message has been scanned for viruses with Symantec Scan Engine and cleared by MailMarshal. ___ -- 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
