Re: Dump Reading (was Re: LSQA shortage)
-- snip -- > > (At least this discussion proves there are still a few of us > still reading dumps. Too bad we all work for ISVs!) Actually, that's "good". As those of us in the "corporate world" tend more and more to be "Sysadmins" rather than "Sysprogs", we are required more and more to depend on our software vendors for problem diagnosis and resolution. We simply can't spare the time to become and remain proficient at dump-diving, mainly because problems requiring dump-diving at a particular installation are so few and far-between any more. -- snip -- I strongly disagree with you. We have to maintain our skill set (even if reading dumps is rare) for numerous reasons. Exactly this post (LSQA shortage) shows that a small amount of dump reading is essential to solving common problems. This problem certainly didn't have anything to do with OCO or IBM/ISV code. We probably also don't need to code much assembler these days (Sysprogs), but most of us are in the position where 'the buck stops here' for any and all kinds of problems. Dump reading is clearly one of our needed skills. Maintaining (better still increasing) our skills is also essential to remain attractive in a difficult market place. --> About now someone should put in a plug for Share and Jerry Ng. John. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Questions on Dedicated Processors
On Wed, 5 Jul 2006 15:35:34 -0400 Jim Mulder <[EMAIL PROTECTED]> wrote: :>David Day <[EMAIL PROTECTED]> wrote on 07/03/2006 05:35:16 PM: :>> 2. The announcement I read states the zIIP does not process :>> general interrupts. That makes sense since they want to dedicate :>> the processor to specific work, so any type of general interrupt :>> needing to be processed has to get handled on a general purpose :>> processor. But the announcement also states the zIIP does not :>> process IO, nor can it handle timer events. Is there more doc :>> available anywhere on what is involved in this part of it? :> z/OS does not use the clock comparator to time events on a zIIP, :>and z/OS does not enable for any interrupt subclasses in control :>register 6 on a zIIP. How does it control a run-away program? Do other parts of WLM check if the ZIIP has been running a piece of code for LONGTIME? -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
hardware compression
Is there an easy way to tell if hardware compression is supported/activated on a mainframe. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
REXX routine to convert TTIME to readable format
Hello , I am trying to interpret SMF data generated by a software. Although I can find routine to convert TOD to readable time format, I can't find a routine to convert TTIME(a time format common in C language) to readable format. Can anyone provide one for me? Regards Victor __ ¸Ï¿ì×¢²áÑÅ»¢³¬´óÈÝÁ¿Ãâ·ÑÓÊÏä? http://cn.mail.yahoo.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
Put messages on JESMSGLG but not Z.LOG
We have a very numerous class of messages we generate which we want to remove from the OPERLOG (where they can be seen from Z.LOG) but retain in the JES2 job messages (JESMSGLG) I believe this should be doable if we change the HARDCOPY statement in CONSOLxx to specify a range of ROUTECDEs that excludes the one used by this class of messages, but it will take me a while to test this. Has any one done any thing similar? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
UNSUBSCRIBE
Thanks, Sreekanth -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Dump Reading (was Re: LSQA shortage)
Bravo! I totally agree especially with the blip about Jerry Ng. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Ticic Sent: Thursday, July 06, 2006 3:07 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Dump Reading (was Re: LSQA shortage) -- snip -- > > (At least this discussion proves there are still a few of us still > reading dumps. Too bad we all work for ISVs!) Actually, that's "good". As those of us in the "corporate world" tend more and more to be "Sysadmins" rather than "Sysprogs", we are required more and more to depend on our software vendors for problem diagnosis and resolution. We simply can't spare the time to become and remain proficient at dump-diving, mainly because problems requiring dump-diving at a particular installation are so few and far-between any more. -- snip -- I strongly disagree with you. We have to maintain our skill set (even if reading dumps is rare) for numerous reasons. Exactly this post (LSQA shortage) shows that a small amount of dump reading is essential to solving common problems. This problem certainly didn't have anything to do with OCO or IBM/ISV code. We probably also don't need to code much assembler these days (Sysprogs), but most of us are in the position where 'the buck stops here' for any and all kinds of problems. Dump reading is clearly one of our needed skills. Maintaining (better still increasing) our skills is also essential to remain attractive in a difficult market place. --> About now someone should put in a plug for Share and Jerry Ng. John. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - 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: Dump Reading (was Re: LSQA shortage)
And what happens when you are gone??? Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Barbara Nitz Sent: Thursday, July 06, 2006 1:26 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Dump Reading (was Re: LSQA shortage) >I guess we are still some people around reading dumps and not being >>ISV's :-)) Hello Barbara ? I'm here! It's not my fault the majority of you gets up when I go to bed! :-) And were you not a lot of hours behind me, I would have immediately suggested to take a dump! (Even though when I do that, I usually get laughed at - 'she and her dumps'!) The LSQA problem: There is still an info apar out there (II05xxx or II06xxx) that describes the basic steps anyone can do to figure out where the problem might be, including "ip verbx vsmdata 'nog summ'". It also explains for the different reason codes where to look and which command to use. In an ibm data base, search for 'abend878 debug'. That can all be done without oco access. In this installation it is 'strongly encouraged' by our management that *I* go and do the dump reading. Solves a lot of problems a lot faster. Don't get me started! 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 - 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: Dump Reading (was Re: LSQA shortage)
It should eb mandatory to debug a dump every so often just to keep your skills up. Even if you have to create the dump yourself. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruno Sugliani Sent: Wednesday, July 05, 2006 4:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Dump Reading (was Re: LSQA shortage) On Wed, 5 Jul 2006 13:48:22 -0500, Mark Zelden <[EMAIL PROTECTED]> wrote: >Me, I read dumps only when I have to. I look at enough to find out >if the abend is in IBM code or an ISV's code. Then I ship the dump to >them after a search on ibm-link or vendor problem data base if one is >available. That is "today's sysprog" - like or not. >The sad part is that most sysprogs I have worked with can't even get >that far with a dump (SHARE IPCS classes should be req'd for all >sysprogs who are not familiar with the basics!). I guess we are still some people around reading dumps and not being ISV's :-)) Hello Barbara ? I guess having done that for a living in our former life , helps a lot but like Mark , now it is only when we need to . Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(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 - 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: hardware compression
Hello Jim, This is a sample I used for checking. It is from the manual, but I don't remember which Itschak CMPCHKSTART BSVA-CMPCHK(,15) DC AL1(8),CL8'CMPCHK' DC CL10'&SYSDATE' DC CL8'/&SYSTIME/' * ** * WRITE SAVE AREA * ** SVA DS 0H EBEGIN EQUR=YES LR 3,1 STM 14,12,12(13) LR 12,15 USINGCMPCHK,12 L7,16GET CVT ADDRESS USINGCVT,7 SET UP ADDRESSABILITY TO TH TM CVTFLAG2,CVTCMPSHIS CMPSC HARDWARE AVAILABLE BZ NO_CMPSC_HARDWARE BRANCH IF NOT AVAILABLE * CMPSC HARDWARE IS AVAILABLE WTO MF=(E,WOK) LA 15,X'00' BENDIT NO_CMPSC_HARDWARE DS 0H DS 0H WTO MF=(E,WERR) LA 15,X'08' * ** ENDIT DS 0H * SVA LR 1,13 L13,4(,13) * FREEMAIN RU,A=(1),LV=72 L14,12(13) LM 2,12,28(13) BR 14 WOK WTO 'CMPSC IS ACTIVE ON THIS MACHINE',MF=L WERR WTO 'CMPSC IS NOT ACTOVE',MF=L CVT DSECT=YES END -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jim McAlpine Sent: Thursday, July 06, 2006 10:45 AM To: IBM-MAIN@BAMA.UA.EDU Subject: hardware compression Is there an easy way to tell if hardware compression is supported/activated on a mainframe. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Dump Reading (was Re: LSQA shortage)
>And what happens when you are gone??? Don't know. They open a problem with xxx and believe what xxx tells them (Make xxx your favourite vendor including IBM). Then they wait for me to come back and bash xxx's heads for not doing their jobs. I am 'elected' to interfere in every problem. I barely managed not to have to open each and every one. (And I refuse to deal with hardware.) In case this was a rhetorical question: They don't read dumps... :-) Barbara -- "Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Obtaining an ACEE for a specified user in CICS
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Walt Farrell > > On 7/5/2006 4:35 PM, Crabtree, Mark wrote: > > Is there a way to obtain a copy of the ACEE for a user (not > the current user) from within CICS? I am using 'EXEC CICS > ADDRESS ACEE(R12)', but this just gets me the ACEE of the > current user. I would like to be able to do this for a user > other than the one running the transaction in order to get a > user's name and connected groups. > > I won't pretend to have much CICS expertise, and so I > hesitate to suggest this since John Chase did not, but how > about having your transaction start another transaction to > run under the ID you want to query, and have that second > transaction return the data to you somehow? Unfortunately, none of the EXEC CICS commands seems able to return the information the OP is seeking. Indeed, it appears one cannot even retrieve one's own group associations except via the ADDRESS ACEE( ) command, then reading the ACEE. -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: Dump Reading (was Re: LSQA shortage)
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Veilleux, Jon L > > And what happens when you are gone??? TEOTWAWKI. -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
CTC's & VTAM
Hi, I am in the process of migrating from a PC Server 500 to a flex laptop. The system runs VM; VSE & OS/390 (all versions very much unsupported). We currently have a CTC connection between VSE & OS/390 that uses the token ring card as the transport. When I move the system the token ring will disappear and I will be using two Flex defined CTC's. What I am after is the VTAM definitions for each end of the CTC's (VSE & OS390) and what the CDRM definitions should look like. Has anyone got any ideas? Kind Regards Mark CSF Group Plc Registered No: 2646774 Registered Office: Alliance House, 49-51 East Road, London, N1 6AH Tel: 0207 490 2727 www.csf.co.uk This email transmission is confidential and intended solely for the person or organisation to whom it is addressed. If you are not the intended recipient, you must not copy, distribute or disseminate the information, or take any action in reliance of it. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of any organisation or employer. If you have received this message in error, do not open any attachment but please notify the sender deleting this message from your system. Security and reliability of e-mail is not guaranteed. In addition, no liability or responsibility is accepted for viruses and it is your responsibility to scan any attachments. Please note that for business purposes, outgoing and incoming emails from and to the company are monitored and recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: VTS stacked tapes - urgent help!
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Chiam, Susan Mee-Shia > Sent: Wednesday, July 05, 2006 9:34 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: VTS stacked tapes - urgent help! > > > Thank you to Jay, Ken and John who have responded. John, I was > enquiring regarding the logical virtual > scratch volumes that I was hoping to reduce so that I could free some > stacked volumes. > Is what you have indicated below is what I was enquiring? If it is, I > will get on with it straight > away! > Yes, doing the LIBRARY EJECT,xx,PURGE command will "erase" volume "xx" in the VTS and free up the space that it was taking on any backstore tape. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LSQA shortage
In a message dated 7/5/2006 11:53:59 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: >At least this discussion proves there are still a few of us still >reading dumps. In addition to the suggestion (by some poster on this or a similar thread) that we all read at least one dump per year to keep in shape, I also suggest doing at least one hexadecimal multiplication by hand per year. A long-hand hex division with pencil and paper is even better. So put that hex calculator down and get at it. Hut-two, hut-two, hut-two. And a long-hand computation of a square root (decimal number system is acceptable) is also a good thing every now and then. Bill Fairchild -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help with TCB status
Binyamin, Chris: Thank you both for your responses. > If you check all the PSA's you should be able to determine if > the task is dispatched. I was also considering the PSA approach by comparing each PSATOLD with the address of the TCB in question. If there's match, then its active. If there's no match and the TCB is not waiting or paused can I assume that it's dispatchable? > If you keep a table of TCBs and you keep both the TCB address and the > TTOKEN value as uniquifiers and you sample both the primary non-dispatch > bit and TCBTTIME you can tell whether or not it was dispatchable when > you looked and whether it is accumulating any cpu time. If you sample > frequently enough then over time, a reasonably valid picture will > emerge. The definition of "frequently enough" is a difficult subject on > its own. The TCBTTIME approach won't work for me since I need to know the status at the time the sample is taken. > If you use TCBTCB as the "next" pointer, ASXBFTCB will get you ALL of > the TCBs in the address space, regardless of dispatchability. I think I misunderstood the ASXBFTCB function. I thought it had a list of dispatchable TCBs only. Regards, Vic -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
JES2 z/OS 1.7 Exit Migration Guide
Hi all Jes2 in Z/os 1.7 have a new adress space (NETSERV). * JES2 z/OS 1.7 Exit Migration Guide Overview * In z/OS 1.7, JES2 moved some processing out of the JES2 main task and address space into other address spaces. This was done to improve performance by reducing the CPU load on the JES2 main task and to provide failure isolation. One of the effects of this change is that main task exits in the moved processing will no longer be called. A new set of exits were provided to give installations and vendors control at the same point of processing as the main task exits. However, these new exits do not run in the JES2 main task (nor in the JES2 address space) and no longer have access to the same data areas as the previous exits. As a result of these changes, installations that use any of the affected exits must examine their code and potentially write code for the new exits. Every effort was made to provide additional function in the new as well as the existing exits to simplify the migration. This document is intended to summarize the improvements made to the exits and to explain how to locate data that was available to the original main task exits. There are 2 approaches that customers can use when evaluating their existing exits. The first is to determine what is needed to migrate existing exits to the new environments with minimal alteration of the logic of the exit code. In most cases, this can be done. The second approach is to determine what the exit logic is doing and to evaluate what is needed to accomplish the same function in the new exits. This approach will often result in much simpler exit logic that is less error prone. However, it will require a larger up front design effort. Jorge Arueira Campos POLITEC-CAIXA ECONOMICA FEDERAL - OSASCO - SP - BRAZIL -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Dump Reading (was Re: LSQA shortage)
My experience is that those who can read dumps do not lack for opportunities to do so. IBM and the ISVs of course and perforce have people who read dumps easily; but, again in my experience, such people have almost no direct contact with these vendors' customers. In the upshot I find people waiting for me, dumps in hand, wherever I go. In this context anyway I would be pleased to be allowed "to get out of practice". John Gilmore Ashland, MA 01721-1817 USA _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
APPC admin utility
Does anyone know the ACF2 rules or where it is documented for the appc administration utility? We are getting the following errors from this. here is a snipit of what we are trying to run and the error we get is in the end: //STEP1EXEC PGM=ATBSDFMU //SYSPRINT DD SYSOUT=* //SYSSDLIB DD DSN=SYS1.APPCTP,DISP=SHR //SYSSDOUT DD SYSOUT=* //SYSINDD DATA,DLM='QT' TPDELETE TPNAME(CATSLRCV) TPADD TPNAME(CATSLRCV) Start of the errors.. LIDAG91V JOB 63543 09.44.57 JOB63543 ACF99913 ACF2 VIOLATION-04,09,LIDAG91,,SYS1.APPCTP,N/A 09.44.57 JOB63543 ACF99913 ACF2 VIOLATION-04,09,LIDAG91,,SYS1.APPCTP,N/A ATB303I APPC administration utility has begun. ATB323I Processing of TPDELETE request has begun. ATB369I Insufficient authority to perform TPDELETE ATB311I TPDELETE request failed. ATB323I Processing of TPADD request has begun. ATB369I Insufficient authority to perform TPADD ATB311I TPADD request failed. ATB307I APPC administration utility processing completed - one or more requests Jim Nagy Software Product Management 4-6136Internal 412-544-6136 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
STC JOBLOG
Dear Listers, Some of the STC joblogs were not placed at Jes2 Hold queue but placed at Jes2 output Queue . Not all the STC joblogs behave like that , just some of them does. They should be placed at hold queue , but no. I had 2 LPARs with the same JES2PARM definition, one of the LPAR runs well , the other one does not. Can anybody show me the way to do with this problem ? Thanks ! Sincerely, Laurence -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Genning a 3745
The EP devices may not come on line until after the PEP is activated on that LPAR. We have some evidence that once activated, the PEP can be deactivated and the devices will remain online. Also, the EP devices could be online to another LPAR. Vary them off over there and try to vary them on to the target LPAR. HTH. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John S. Giltner, Jr. Sent: Wednesday, July 05, 2006 9:02 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Genning a 3745 Bruce McKnight wrote: > Greetings all, > > Got a question about genning a 3745. I'm adding a defintion to our > z890 running z/OS 1.4 and using the definition in our z800 running > OS/390 2.9 as a model. I have a single control unit attached to the > CHPID with address ranges of 0001 (for the 3745 itself) and 0060 thru > 0064 as BSC2 devices. > > The report looks like it's doubling up the devices. The report is > normal on the z800. > > UNIT ADDRUNIT > RANGE-- DEVICE -- ADDR DEVICE > FROM TO NUMBER,RANGE START TYPE-MODE > _ _ _ > > 01 01 0001 013745 > 0060,5 60BSC2 > 60 7F 0001 013745 > 0060,5 60BSC2 > > The CHPID comes online ok but the devices don't. The console say's > there's no path. > > Any ideas? > > Thanks, > Bruce > 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: APPC admin utility
-04 means you do not have WRITE(A) access to the dataset. You need to update the SYS1 rule. Regards, John Kalinich Computer Sciences Corp Jim Nagy <[EMAIL PROTECTED] ARK.COM> To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List <[EMAIL PROTECTED] Subject .EDU> APPC admin utility 07/06/2006 09:07 AM Please respond to IBM Mainframe Discussion List <[EMAIL PROTECTED] .EDU> Does anyone know the ACF2 rules or where it is documented for the appc administration utility? We are getting the following errors from this. here is a snipit of what we are trying to run and the error we get is in the end: //STEP1EXEC PGM=ATBSDFMU //SYSPRINT DD SYSOUT=* //SYSSDLIB DD DSN=SYS1.APPCTP,DISP=SHR //SYSSDOUT DD SYSOUT=* //SYSINDD DATA,DLM='QT' TPDELETE TPNAME(CATSLRCV) TPADD TPNAME(CATSLRCV) Start of the errors.. LIDAG91V JOB 63543 09.44.57 JOB63543 ACF99913 ACF2 VIOLATION-04,09,LIDAG91,,SYS1.APPCTP,N/A 09.44.57 JOB63543 ACF99913 ACF2 VIOLATION-04,09,LIDAG91,,SYS1.APPCTP,N/A ATB303I APPC administration utility has begun. ATB323I Processing of TPDELETE request has begun. ATB369I Insufficient authority to perform TPDELETE ATB311I TPDELETE request failed. ATB323I Processing of TPADD request has begun. ATB369I Insufficient authority to perform TPADD ATB311I TPADD request failed. ATB307I APPC administration utility processing completed - one or more requests Jim Nagy -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: problem with spool volume serial
Dorota, Just out of curiousity did you/were you able to find out why this is happening? I am also running into this issue and would like to know why. Thanks. Ann -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Howards VSAM problem
Ed, because the system was poorly maintained for years, starved for money and people, maintained by applications people, systems programmers and the like who didn't know they didn't know and were left to run wild and had no idea of what the term 'best practices' ment...no clue. Ed Gould <[EMAIL PROTECTED]> wrote: > Good ideas John, > > The problem is that on both lpars the master catalogs are the > same names and the datasets on the test lpar are in the master > catalog. > I know I shouldn't ask but what is a USER VSAM dataset doing in a mastercat? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Obtaining an ACEE for a specified user in CICS
On 7/6/2006 8:09 AM, Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Walt Farrell On 7/5/2006 4:35 PM, Crabtree, Mark wrote: Is there a way to obtain a copy of the ACEE for a user (not the current user) from within CICS? I am using 'EXEC CICS ADDRESS ACEE(R12)', but this just gets me the ACEE of the current user. I would like to be able to do this for a user other than the one running the transaction in order to get a user's name and connected groups. I won't pretend to have much CICS expertise, and so I hesitate to suggest this since John Chase did not, but how about having your transaction start another transaction to run under the ID you want to query, and have that second transaction return the data to you somehow? Unfortunately, none of the EXEC CICS commands seems able to return the information the OP is seeking. Indeed, it appears one cannot even retrieve one's own group associations except via the ADDRESS ACEE( ) command, then reading the ACEE. True, but if he can start another transaction to run under the desired ID, could that transaction address its own ACEE, extract the information directly, and return it to the original transaction in some way? Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Relabelling a 3592 in an ATL
Sorry, I know this is not directly mainframe related. But we have a problem that our tape librarian has dumped in our laps. We have an ATL with 3952 drives. We also have an VTS connected to this same ATL. Our backstore tapes are 3952s. This ATL is also used for our Distributed (Windows) systems. The tape librarian wants to relabel some "distributed" tapes to be VTS "backstore" tapes. First question. Are VTS backstore tapes internally labelled? If so, what type of label? Second question. What would be the easiest way to "insert" these tapes into the z/OS managed portion of the library so that I could appropriately label them? Has anybody done this? IBM's initial suggestion is to get the tapes together and send them back to our original supplier and ask them to do the relabelling for us. I like this solution. However, it costs money. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: STC JOBLOG
On Thu, 6 Jul 2006 14:18:17 +, Tsai Laurence <[EMAIL PROTECTED]> wrote: >Dear Listers, > Some of the STC joblogs were not placed at Jes2 Hold queue but placed at >Jes2 output Queue . Not all the STC joblogs behave like that , just some of >them does. They should be placed at hold queue , but no. I had 2 LPARs with >the same JES2PARM definition, one of the LPAR runs well , the other one >does not. >Can anybody show me the way to do with this problem ? >Thanks ! > Are you sure the "running" definitions are the same? Verify with $DJOBCLASS(STC) in each environment. Also, are STARTED JOBs being used changing the jobcard msgclass etc.? What about the START command itself for the STCs in question (JOB keywords can be overridden on the start command)? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ 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: Relabelling a 3592 in an ATL
If you are talking physical cartridges, here is what we did. We inherited an ATL from the LAn group. All cartridges were removed and had new Z/OS numbers put on them, barcoded labels. Then we tossed them back inside. When a job asks for a scratch, it is relabeled then by the system. This has to do with an auto-response from our system, granted, but if the automation isn't present, then a WTOR is generated. I'm not sure if this answers your question or not, but it was our experience. Daniel McLaughlin ZOS Systems Programmer Crawford & Company PH: 770 621 3256 * One seventh of your life is spent on Monday. - Unknown -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Obtaining an ACEE for a specified user in CICS
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Walt Farrell > > On 7/6/2006 8:09 AM, Chase, John wrote: > >> -Original Message- > >> From: IBM Mainframe Discussion List On Behalf Of Walt Farrell > >> > >> I won't pretend to have much CICS expertise, and so I hesitate to > >> suggest this since John Chase did not, but how about having your > >> transaction start another transaction to run under the ID you want to > >> query, and have that second transaction return the data to you > >> somehow? > > > > Unfortunately, none of the EXEC CICS commands seems able to return the > > information the OP is seeking. Indeed, it appears one cannot even > > retrieve one's own group associations except via the ADDRESS ACEE( ) > > command, then reading the ACEE. > > True, but if he can start another transaction to run under > the desired ID, could that transaction address its own ACEE, > extract the information directly, and return it to the > original transaction in some way? Yes, that should work. The original question just got posed on the CICS-L, with some additional information that suggested the original way of extracting the information was to issue an SVC that switched CICS to authorized state, issued the RACROUTE and (hopefully) returned CICS to unauthorized state. Apparently something "new" in CICS TS 3.1 "catches" that switch (sometimes) and abends the program. I've suggested there that they recode their SVC to issue the RACROUTE from within the SVC and return the results to the program via the "normal" return from the SVC. -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: RMM Retention type of HSM incremental backups
Ginnie, I think that you do not have to have the alternate tapes back in order to do recycle processing. HSM recycles the primary copies, then calls TVEXT with the volsers of primary and alternate tapes. RMM releases those volumes. If any alternate tapes are offsite when released they will be moved back automatically by RMM from the offsite location. So, if you recyle all those 5 days worth of volumes you get all5 days of the alternate tapes back in one go. Mike Wood RMM Development On Thu, 29 Jun 2006 16:57:54 -0500, Ginnie Nuckles <[EMAIL PROTECTED]> wrote: >We are running incremental backups nightly. We want to duplex this process >thereby creating a copy of the incremental tapes. By default HSM creates >all of these backup tapes with the name of DFHSM.COPY.BACKTAPE.DATASET. >This creates a problem with defining a VSR (vital statistics record) that >sends monday - fridays incremental copies to an offsite location. then >recalls all five days back at the same time for recycle processing .. I >hope this makes sense.. I cannot figure this out. Everything looks like its >designed to move only one tape in or out of a location at a time ,, >(especially when the tapes created all have the same dataset name) .. > >all help welcome >Ginnie Nuckles > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >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: Relabelling a 3592 in an ATL
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Daniel A. McLaughlin > Sent: Thursday, July 06, 2006 10:19 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: Relabelling a 3592 in an ATL > > > If you are talking physical cartridges, here is what we did. > We inherited > an ATL from the LAn group. All cartridges were removed and > had new Z/OS > numbers put on them, barcoded labels. Then we tossed them > back inside. > When a job asks for a scratch, it is relabeled then by the > system. This > has to do with an auto-response from our system, granted, but if the > automation isn't present, then a WTOR is generated. > > I'm not sure if this answers your question or not, but it was our > experience. Thanks. I know how to initialiaze them if I need them to be z/OS tapes. It is the VTS "backstore" part that is confusing everybody. For all I know, they are not labelled internally at all. Nobody seems to be able to answer that question. So far. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Relabelling a 3592 in an ATL
I see. We aren't using VTS, so I was stating the obvious, a trait of us dinosaurs. Daniel McLaughlin ZOS Systems Programmer Crawford & Company PH: 770 621 3256 * One seventh of your life is spent on Monday. - Unknown -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: hardware compression
Hello Itschak, and thank you for that code. Is EBEGIN one of your macros. If so, what does it do. Jim McAlpine On 7/6/06, Itschak Mugzach <[EMAIL PROTECTED]> wrote: Hello Jim, This is a sample I used for checking. It is from the manual, but I don't remember which Itschak -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: hardware compression
Here is a rexx:
/* REXX */
CVT = STORAGE(10,4) /* CVT ADDRESS IN MEMORY */
SCVT = STORAGE(D2X(200+C2D(CVT)),4) /* ADDRESS OF SCVT */
CCVT = STORAGE(D2X(184+C2D(SCVT)),4) /* ADDRESS OF CCVT */
IF CCVT = ''X THEN DO
say 'Cryptography Not Installed'
EXIT(0)
END
ELSE DO
CCVTFL = STORAGE(D2X(36+C2D(CCVT)),1) /* CCVTSFG1 STATUS BYTE */
IF BITAND(CCVTFL,'80'X) <> '80'X THEN DO
say 'Cryptography is Installed',
'but is Inactive'
EXIT(0)
END
ELSE DO
say 'Cryptography is Active'
CCVTAS = STORAGE(D2X(42+C2D(CCVT)),2) /* CCVTASID ASID OF ICSF */
say 'ASID of ICSF/MVS Address Space is' c2x(ccvtas) '('c2d(ccvtas)')'
EXIT(0)
END
END
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of Jim McAlpine
Sent: Thursday, July 06, 2006 11:41 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: hardware compression
Hello Itschak, and thank you for that code. Is EBEGIN one of your macros.
If so, what does it do.
Jim McAlpine
On 7/6/06, Itschak Mugzach <[EMAIL PROTECTED]> wrote:
>
> Hello Jim,
>
> This is a sample I used for checking. It is from the manual, but I don't
> remember which
>
> Itschak
>
>
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
-
CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System
intends this e-mail message, and any attachments, to be used only
by the person(s) or entity to which it is addressed. This message
may contain confidential and/or legally privileged information. If
the reader is not the intended recipient of this message or an
employee or agent responsible for delivering the message to the
intended recipient, you are hereby notified that you are prohibited
from printing, copying, storing, disseminating or distributing this
communication. If you received this communication in error, please
delete it from your computer and notify the sender by reply e-mail.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Dump Reading (was Re: LSQA shortage)
Veilleux, Jon L wrote: It should be mandatory to debug a dump every so often just to keep your skills up. Even if you have to create the dump yourself. Mark Z was right when he guessed that most of the dumps Chris and I read are produced by products for which we have the source code. But, in my case, I certainly don't stop there. I make it a point to analyze (albeit sometimes just briefly) every dump I send to IBM associated with any PMR I've opened. And, every once in a while, that analysis comes in handy! IBM has some absolutely amazing dump readers. (Jim Mulder and Nadine Goldberg have to be at or near the top of the list!) But, even some support technicians at IBM are afraid of reading dumps. I've experienced numerous situations in which it was obvious that Level 2 was doing everything possible to avoid that "chore" -- sending me off to gather input parameters, logs, attempt additional recreates, etc. when all anyone had to do was crack open the dump for a few minutes (with the program listing handy) to understand what went wrong! I had one such incident in which RMM was down for _three days_ while Level 2 flapped around like a fish on the ground until, out of desperation, I contacted Mike Wood (RMM guru and IBM-Main participant), who figured out the problem and provided a workaround after only _ten minutes_ of dump analysis -- something the Level 2 technician had never even attempted! There have been other cases in which I've found myself leading the dump analysis process from my end (sometimes with and often without source code or listings!) because Level 2 was asking all the wrong questions and I knew it because I had already looked at the dump myself! Recently, I've started saying things like, "I'm sorry. The information you've asked for is no longer available on my system. You'll just have to solve this problem the 'old fashioned' way -- by analyzing the dump!" I'll even start the ball rolling by providing as much as I know about the problem. It's amazing how quickly things progress when people start actually focusing on the wealth of information provided by the dump! Postmortem problem analysis is an area in which the mainframe remains light-years ahead of other platforms. It's truly a cultural difference. The direct and demonstrable result is the quality and reliability of our software. We should not allow ourselves to lose that important differentiator. Reading dumps can be fun. Do it when you can and you'll be helping to keep the mainframe community's postmortem problem analysis skills current... -- 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: Help with TCB status
=== -Original Message- From: "Vic Petrone" <[EMAIL PROTECTED]> Sent: 7/6/2006 7:18 AM To: "IBM-MAIN@BAMA.UA.EDU" Subject: Re: Help with TCB status Binyamin, Chris: Thank you both for your responses. > If you check all the PSA's you should be able to determine if > the task is dispatched. I was also considering the PSA approach by comparing each PSATOLD with the address of the TCB in question. If there's match, then its active. If there's no match and the TCB is not waiting or paused can I assume that it's dispatchable? /snip/ Regards, Vic === Greetings, Looking at all PSA probably won't work unless you are running disabled, and then be prepared for a "foreign" PSA that may have a PSATOLD that just happens to match one your TCB pointers but it is in another address space dispatched on that "foreign" PSA. You'll want to check simultaneously the PSATOLD and PSAAOLD values, and you must be disabled while looping through the other PSA. Probably better to just use the TCB pointer chains while holding the local lock. 2 cents worth. Your mileage may vary. Jeffrey D. Smith Farsight Systems Corporation 24 BURLINGTON DR LONGMONT, CO 80501 303-774-9381 direct 303-709-8153 cell 303-484-6170 fax -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: hardware compression
==
-Original Message-
From: "Tribble, Robert" <[EMAIL PROTECTED]>
Sent: 7/6/2006 9:44 AM
To: "IBM-MAIN@BAMA.UA.EDU"
Subject: Re: hardware compression
Here is a rexx:
/* REXX */
CVT = STORAGE(10,4) /* CVT ADDRESS IN MEMORY */
SCVT = STORAGE(D2X(200+C2D(CVT)),4) /* ADDRESS OF SCVT */
CCVT = STORAGE(D2X(184+C2D(SCVT)),4) /* ADDRESS OF CCVT */
IF CCVT = ''X THEN DO
say 'Cryptography Not Installed'
EXIT(0)
END
ELSE DO
CCVTFL = STORAGE(D2X(36+C2D(CCVT)),1) /* CCVTSFG1 STATUS BYTE */
IF BITAND(CCVTFL,'80'X) <> '80'X THEN DO
say 'Cryptography is Installed',
'but is Inactive'
EXIT(0)
END
ELSE DO
say 'Cryptography is Active'
CCVTAS = STORAGE(D2X(42+C2D(CCVT)),2) /* CCVTASID ASID OF ICSF */
say 'ASID of ICSF/MVS Address Space is' c2x(ccvtas) '('c2d(ccvtas)')'
EXIT(0)
END
END
==
Greetings,
Your example is describing the ICSF (Cryptographic Services), not
compression. The OP was asking about hardware compression
availability.
Also, the publicly documented crypto instructions (KM, KMC, KMAC, etc.)
may be available even though the CCVT pointer is NULL. The only way to
know for sure is to try KM (with the query function code in R0) and
catch the potential S0C1-01 abend.
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DR
LONGMONT, CO 80501
303-774-9381 direct
303-709-8153 cell
303-484-6170 fax
--
For IBM-MAIN subscribe / signoff / archive access instructions,
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: Obtaining an ACEE for a specified user in CICS
John Chase wrote: > The original question just got posed on the CICS-L, with some additional > information that suggested the original way of extracting the > information was to issue an SVC that switched CICS to authorized state, > issued the RACROUTE and (hopefully) returned CICS to unauthorized state. > Apparently something "new" in CICS TS 3.1 "catches" that switch > (sometimes) and abends the program. > > I've suggested there that they recode their SVC to issue the RACROUTE > from within the SVC and return the results to the program via the > "normal" return from the SVC. Their existing approach is a definite integrity hole! No ifs, buts or maybes. The only correct way to perform a function such as this on behalf of an unauthorized caller is to encapsulate that function within an appropriately authorized environment and the only reasonable choices are PC and SVC. But while I'm on that soap box, obtaining some other user's credentials is an authorized function because only a properly authorized resource manager has any right to access them. John Q. certainly does not and providing a wrapper for a function that will do so is just as much a security violation as writing the password on a sticky note next to the terminal. People have to remember that any code they write and install in the system can also be called (often creatively) by "black hats". Just because you wrote it for CICS doesn't mean some ingenious twerp can't fool it into doing something "bad" from some other more user-friendly environment like TSO. (Blech... did I just use "user friendly" and TSO in the same sentence? Must be getting old) CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCP/IP and connecting z to alternate platforms
Len Rugen wrote: >Depending on your traffic workload, a Cisco CIP can be VERY usefull for >TN3270 traffic. Our CIP is the tn3270 server, frontended by Cisco SSL >hardware. The Cisco CIP looks like SNA 3270 devices instead of IP devices. >Those connect to VTAM directly, without I/O thru the TCPIP stack on z/OS or >the crypto chips (that we don't have). That's really the difference, the crypto, not the VTAM (SNA) v. TCP/IP. If you have something like a Multiprise 3000 and you're using TN3270 with SSL/TLS then the encryption can be rather CPU intensive (and you don't have OSA Express helping out there either). If you're headed to, say, a System z9 then I'd revisit this issue because you could end up with a much simpler (and less expensive) installation. Crypto hardware has changed rather quickly, and every system now ships with at least some. (Make sure it's turned on and used to maximum effect, of course.) There are Communications Server for z/OS performance reports that you can find on the IBM Web site. I'd look at reports from a few different Communications Server releases to get a feel for the data. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries IBM Japan, Ltd. E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help with TCB status
> <> dispatchability isn't sufficient to > ensure that the TCB can be dispatched; it must also have a ready RB at > the top of the stack. If you don't have a ready RB at the top of the RB stack you are (by definition) not dispatchable. After all, what would be dispatched? But (and I think this is the point you meant to make) being dispatchable does not have much bearing on whether or not a TCB is actually running at the moment you looked at it. If there isn't a cpu available, or if the task isn't at the head of the next-to-be-dispatched web queue, then its not going to run. Being non-dispatchable is a deal breaker, but being dispatchable only means that you're eligible to run "some time". CC -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Dump Reading (was Re: LSQA shortage)
AMEN! You should NEVER send a dump to any vendor without at least doing some cursory dump analysis. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Thursday, July 06, 2006 11:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Dump Reading (was Re: LSQA shortage) Veilleux, Jon L wrote: > It should be mandatory to debug a dump every so often just to keep > your skills up. Even if you have to create the dump yourself. > Mark Z was right when he guessed that most of the dumps Chris and I read are produced by products for which we have the source code. But, in my case, I certainly don't stop there. I make it a point to analyze (albeit sometimes just briefly) every dump I send to IBM associated with any PMR I've opened. And, every once in a while, that analysis comes in handy! IBM has some absolutely amazing dump readers. (Jim Mulder and Nadine Goldberg have to be at or near the top of the list!) But, even some support technicians at IBM are afraid of reading dumps. I've experienced numerous situations in which it was obvious that Level 2 was doing everything possible to avoid that "chore" -- sending me off to gather input parameters, logs, attempt additional recreates, etc. when all anyone had to do was crack open the dump for a few minutes (with the program listing handy) to understand what went wrong! I had one such incident in which RMM was down for _three days_ while Level 2 flapped around like a fish on the ground until, out of desperation, I contacted Mike Wood (RMM guru and IBM-Main participant), who figured out the problem and provided a workaround after only _ten minutes_ of dump analysis -- something the Level 2 technician had never even attempted! There have been other cases in which I've found myself leading the dump analysis process from my end (sometimes with and often without source code or listings!) because Level 2 was asking all the wrong questions and I knew it because I had already looked at the dump myself! Recently, I've started saying things like, "I'm sorry. The information you've asked for is no longer available on my system. You'll just have to solve this problem the 'old fashioned' way -- by analyzing the dump!" I'll even start the ball rolling by providing as much as I know about the problem. It's amazing how quickly things progress when people start actually focusing on the wealth of information provided by the dump! Postmortem problem analysis is an area in which the mainframe remains light-years ahead of other platforms. It's truly a cultural difference. The direct and demonstrable result is the quality and reliability of our software. We should not allow ourselves to lose that important differentiator. Reading dumps can be fun. Do it when you can and you'll be helping to keep the mainframe community's postmortem problem analysis skills current... -- 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 - 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: Help with TCB status
Vic wrote: > > > If you check all the PSA's you should be able to determine if > > the task is dispatched. > > I was also considering the PSA approach by comparing each PSATOLD with the > address of the TCB in question. If there's match, then its active. If > there's no match and the TCB is not waiting or paused can I assume that > it's dispatchable? No, you have to simultaneously compare PSAAOLD with the address space you're interested in and PSATOLD with the task you are interested in because you will find TCBs at the same address in many address spaces. One "creative" way to do this is PLO.CL where you use the ASCB address as the compare value for PSAAOLD and load from PSATOLD. If the compare fails you just skip that PSA because the associated cpu isn't executing any task (or SRB) in that address space. But even if the TCB you're interested in happens to appear to be dispatched at the moment you looked, there's no guarantee at all that it is still running at the end of the instruction(s) you used to decide that it was running. That's the "feature" of asynchronous execution, there's just no way to know for sure what the state of any other unit of work is from moment to moment. > The TCBTTIME approach won't work for me since I need to know the status at > the time the sample is taken. If you are disabled at the point you begin your scan of the PSA's and the TCB you want really is active at that moment, then there is more likelihood that you will "catch it in the act". But, once again, no guarantees. You can get (legally) disabled by obtaining the CPU lock prior to the PSA scan and releasing it afterward. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Help with TCB status
= -Original Message- From: "Craddock, Chris" <[EMAIL PROTECTED]> Sent: 7/6/2006 10:36 AM To: "IBM-MAIN@BAMA.UA.EDU" Subject: Re: Help with TCB status Vic wrote: > > > If you check all the PSA's you should be able to determine if > > the task is dispatched. > > I was also considering the PSA approach by comparing each PSATOLD with the > address of the TCB in question. If there's match, then its active. If > there's no match and the TCB is not waiting or paused can I assume that > it's dispatchable? No, you have to simultaneously compare PSAAOLD with the address space you're interested in and PSATOLD with the task you are interested in because you will find TCBs at the same address in many address spaces. One "creative" way to do this is PLO.CL where you use the ASCB address as the compare value for PSAAOLD and load from PSATOLD. If the compare fails you just skip that PSA because the associated cpu isn't executing any task (or SRB) in that address space. /snip/ = Greetings, Oops, Chris! You cannot use PLO instruction to synchronously load PSAAOLD and PSATOLD. PLO doesn't perform interlocked access. Multiple CPU must agree on what R1 points to, before PLO has any meaning. The comparison may show equal, but then another CPU can store anything into PSATOLD before your PLO fetches it. It's not different than an ordinary compare, branch, load sequence when other CPU are not respecting your PLO. Jeffrey D. Smith Farsight Systems Corporation 24 BURLINGTON DR LONGMONT, CO 80501 303-774-9381 direct 303-709-8153 cell 303-484-6170 fax -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Help with TCB status
Craddock, Chris wrote: No, you have to simultaneously compare PSAAOLD with the address space you're interested in and PSATOLD with the task you are interested in because you will find TCBs at the same address in many address spaces. One "creative" way to do this is PLO.CL where you use the ASCB address as the compare value for PSAAOLD and load from PSATOLD. If the compare fails you just skip that PSA because the associated cpu isn't executing any task (or SRB) in that address space. Are you sure PLO can be used this way? Will the "compare" portion work against arbitrary values not serialized/updated using PLO? -- 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: Obtaining an ACEE for a specified user in CICS
On 7/6/2006 12:01 PM, Craddock, Chris wrote: John Chase wrote: I've suggested there that they recode their SVC to issue the RACROUTE from within the SVC and return the results to the program via the "normal" return from the SVC. ...snipped... But while I'm on that soap box, obtaining some other user's credentials is an authorized function because only a properly authorized resource manager has any right to access them. John Q. certainly does not and providing a wrapper for a function that will do so is just as much a security violation as writing the password on a sticky note next to the terminal. As described they are not "obtaining some other user's credentials". They are obtaining the other user's name and group connection information. Obtaining the credentials would involve actually getting a usable (e.g., attached to a TCB) copy of the other user's ACEE. People have to remember that any code they write and install in the system can also be called (often creatively) by "black hats". Just because you wrote it for CICS doesn't mean some ingenious twerp can't fool it into doing something "bad" from some other more user-friendly environment like TSO. True. And that makes a PC a more advisable implementation than an SVC for this case, in my opinion. They could front-end the execution of CICS with a program that would verify that it was a job-step task, and would define a PC available only within its own address space, and then transfer control to CICS for the rest of its initialization processing. Then the function could not be invoked from other environments. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: hardware compression
Although there is a CVT flag that indicates compression support, all IBM processors built in the last 10 years or so have the support. You are unlikely to be running on a system without compression support. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.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: Relabelling a 3592 in an ATL
John, I believe that all you will need to do is physically eject the cartridges and then put them back in. The "trick" is that when you put the physical cartridges back in, you must specify (from the 3494 station) that the cartridges are being put back in as scratch stacking volumes. This is a different "insert" process then when you simply "insert" a cartridge and someone (a z/OS system or a distributed system) takes "ownership" of them. Instead, you are telling the 3494 that these are physical tapes for it to use itself as a "stacking" cartridge. Russell Witt -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of McKown, John Sent: Thursday, July 06, 2006 10:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Relabelling a 3592 in an ATL Sorry, I know this is not directly mainframe related. But we have a problem that our tape librarian has dumped in our laps. We have an ATL with 3952 drives. We also have an VTS connected to this same ATL. Our backstore tapes are 3952s. This ATL is also used for our Distributed (Windows) systems. The tape librarian wants to relabel some "distributed" tapes to be VTS "backstore" tapes. First question. Are VTS backstore tapes internally labelled? If so, what type of label? Second question. What would be the easiest way to "insert" these tapes into the z/OS managed portion of the library so that I could appropriately label them? Has anybody done this? IBM's initial suggestion is to get the tapes together and send them back to our original supplier and ask them to do the relabelling for us. I like this solution. However, it costs money. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: avgrec/avgblk history ?
On Jul 6, 2006, at 12:08 AM, Paul Gilmartin wrote: On Wed, 5 Jul 2006 22:21:07 -0500, Ed Gould <[EMAIL PROTECTED]> wrote: The SAMe SU (IIRC) assumed that all blocks would be the same size except for the last. I don't recall of finding short blocks in any of the QSAM type datasets sine the SAMe came out. I don't recall of a programmer ever needing a short block. While there may b e a few out there I have never run across them personally. It has long been possible to create interior short blocks by at least the following techniques: o RECFM=V o DISP=MOD I doubt that SAMe would have had the influence to change either of those. -- gil Gil, WHile that is true no programmer I ever ran into, ever trusted "MOD" . Yes it does work though. The programmers really only use of mod was in checkpoint restart tape. Even then it was grimaced at. Back in the "old times" uptime was at best bad (can we say 5 minutes?) so no one really trusted it (MOD). Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: APPC admin utility
we are able to get rid of the sys1 error by writing a rule for that, but there is more to appc admin. that we need to write That is what I need help with. Thanks Jim Nagy Software Product Management 4-6136Internal 412-544-6136 -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Howards VSAM problem
Howard, Good its an opportunity for you to fix the problems. Ed On Jul 6, 2006, at 9:38 AM, Howard Rifkind wrote: Ed, because the system was poorly maintained for years, starved for money and people, maintained by applications people, systems programmers and the like who didn't know they didn't know and were left to run wild and had no idea of what the term 'best practices' ment...no clue. Ed Gould <[EMAIL PROTECTED]> wrote: > Good ideas John, The problem is that on both lpars the master catalogs are the same names and the datasets on the test lpar are in the master catalog. I know I shouldn't ask but what is a USER VSAM dataset doing in a mastercat? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - Sneak preview the all-new Yahoo.com. It's not radically different. Just radically better. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Dump Reading (was Re: LSQA shortage)
Edward Jaffe wrote: > But, even some support technicians at IBM are afraid of > reading dumps. I've experienced numerous situations in which it > was obvious that Level 2 was doing everything possible to > avoid that "chore" -- sending me off to gather input > parameters, logs, attempt additional recreates, etc. when all > anyone had to do was crack open the dump for a few minutes > (with the program listing handy) to understand what went wrong! Heh heh... A couple of years ago a customer of ours had a loop when calling one of our Java programs. From the dump (including eventually a branch trace), I determined that the loop was entirely in the IBM JVM, and told them so. They insisted that we were repeatedly calling a Java function. > It's amazing how quickly things progress when people start actually > focusing on the wealth of information provided by the dump! In this case (and sadly, in a number of cases I've encountered) they didn't want to listen. I eventually figured out the offset of the bad loop test in the (OCO of course) JVM, and told them to look at their PL/X generated listing at that offset in DLL so-and-so. Naturally I expected a medal from IBM... :-) Instead an APAR fix was issued without comment or acknowledgement. Such is life at the bits & bytes end of ISV land. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: avgrec/avgblk history ?
I trust MOD all the time! I never had a problem with MOD. Lots of good uses for MOD, not the least of which is DISP=(MOD,DELETE) for deleting those pesky "might be there, might not" datasets and DISP=(MOD,CATLG) for creating them. Charles P.S. This will inevitably start three new threads: one a nostalgia thread on "I remember when PCP Rel. 12 had a bug in DISP=MOD," one on "most creative uses for DISP=MOD" (and then why some alternative approach is MUCH better), and one on "why DISP=MOD is vastly superior to (or alternatively, vastly inferior to) UNIX open append" . -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Thursday, July 06, 2006 10:59 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: avgrec/avgblk history ? WHile that is true no programmer I ever ran into, ever trusted "MOD" . Yes it does work though. The programmers really only use of mod was in checkpoint restart tape. Even then it was grimaced at. Back in the "old times" uptime was at best bad (can we say 5 minutes?) so no one really trusted it (MOD). -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Obtaining an ACEE for a specified user in CICS
Walt said; > As described they are not "obtaining some other user's credentials". > They are obtaining the other user's name and group connection > information. Obtaining the credentials would involve actually getting a > usable (e.g., attached to a TCB) copy of the other user's ACEE. Sorry, my bad. I had the impression that was exactly what they wanted. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: avgrec/avgblk history ?
On Thu, 6 Jul 2006 12:58:50 -0500, Ed Gould <[EMAIL PROTECTED]> wrote: > > >> The SAMe SU (IIRC) assumed that all blocks would be the same size > >> except for the last. I don't recall of finding short blocks in any of > >> the QSAM type datasets sine the SAMe came out. I don't recall of a > >> programmer ever needing a short block. While there may b e a few out > >> there I have never run across them personally. > >> > > It has long been possible to create interior short blocks by at > > least the following techniques: > > > > o RECFM=V > > > > o DISP=MOD > > > > I doubt that SAMe would have had the influence to change either > > of those. > > > > -- gil > Gil, > > WHile that is true no programmer I ever ran into, ever trusted > "MOD" . Yes it does work though. The programmers really only use of > mod was in checkpoint restart tape. Even then it was grimaced at. > Back in the "old times" uptime was at best bad (can we say 5 > minutes?) so no one really trusted it (MOD). > This is the first I have heard of unreliability of DISP=MOD. Is that the consensus of readers here? That said, my most frequent uses of MOD are for its collateral effects: o Conditionally create a data set in an IEFBR14 step with DISP=(MOD,CATLG), then write it in a subsequent step with DISP=OLD. o Conditionally delete a data set with DISP=(MOD,DELETE). o DISP=MOD,DSN=HLQ.LLQ(&MEMBER) to prevent overwriting an existing member. I've distributed some JCL using this, and about once a year I get a phone call about a Sx14 ABEND. Generally, the caller is grateful when I remind him he was about to overwrite, and renames the existing member for backup. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Howards VSAM problem
No longer worth while...the box is going to be replace in favor of blade servers running linux. I was told that this is the wave of the future. Ed Gould <[EMAIL PROTECTED]> wrote: Howard, Good its an opportunity for you to fix the problems. Ed On Jul 6, 2006, at 9:38 AM, Howard Rifkind wrote: > Ed, because the system was poorly maintained for years, starved for > money and people, maintained by applications people, systems > programmers and the like who didn't know they didn't know and were > left to run wild and had no idea of what the term 'best practices' > ment...no clue. > > Ed Gould wrote: > Good ideas John, >> >> The problem is that on both lpars the master catalogs are the >> same names and the datasets on the test lpar are in the master >> catalog. >> > > I know I shouldn't ask but what is a USER VSAM dataset doing in a > mastercat? > > Ed > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > - > Sneak preview the all-new Yahoo.com. It's not radically different. > Just radically better. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > 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 - Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: avgrec/avgblk history ?
At one time, and I don't know if it still works this way, if you allocated a temporary dataset with disp=mod,pass and didn't open it in the first step, when you opened it in the second step with disp=mod, it would read the residual data from the work disk at the point where the file was allocated. We ran into this in an ASML proc where the LINK step had garbage when the SYSLIN wasn't opened in the ASM step. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Thursday, July 06, 2006 2:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: avgrec/avgblk history ? On Thu, 6 Jul 2006 12:58:50 -0500, Ed Gould <[EMAIL PROTECTED]> wrote: > > >> The SAMe SU (IIRC) assumed that all blocks would be the same size > >> except for the last. I don't recall of finding short blocks in any > >> of the QSAM type datasets sine the SAMe came out. I don't recall of > >> a programmer ever needing a short block. While there may b e a few > >> out there I have never run across them personally. > >> > > It has long been possible to create interior short blocks by at > > least the following techniques: > > > > o RECFM=V > > > > o DISP=MOD > > > > I doubt that SAMe would have had the influence to change either of > > those. > > > > -- gil > Gil, > > WHile that is true no programmer I ever ran into, ever trusted "MOD" . > Yes it does work though. The programmers really only use of mod was > in checkpoint restart tape. Even then it was grimaced at. > Back in the "old times" uptime was at best bad (can we say 5 > minutes?) so no one really trusted it (MOD). > This is the first I have heard of unreliability of DISP=MOD. Is that the consensus of readers here? That said, my most frequent uses of MOD are for its collateral effects: o Conditionally create a data set in an IEFBR14 step with DISP=(MOD,CATLG), then write it in a subsequent step with DISP=OLD. o Conditionally delete a data set with DISP=(MOD,DELETE). o DISP=MOD,DSN=HLQ.LLQ(&MEMBER) to prevent overwriting an existing member. I've distributed some JCL using this, and about once a year I get a phone call about a Sx14 ABEND. Generally, the caller is grateful when I remind him he was about to overwrite, and renames the existing member for backup. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - 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: Help with TCB status
Ed (and Jeff Smith) asked > Are you sure PLO can be used this way? Will the "compare" portion work > against arbitrary values not serialized/updated using PLO? Well now that you mention it, I'm NOT sure. The compare and load functions are supposed to be for following chains that can change while you're looking at them. I had a conversation about PLO with Bob Rogers a long time ago and came away with the impression that the operands were fetched (in the normal way) -before- the comparison was made, so if you got CC=0 then, at least in the compare and load case, you had a point-in-time consistent view which is all that I wanted. I haven't actually used this "trick" anywhere and since it might not actually work the way I thought, I won't use it. I can't blame Bob because I was probably reading between the lines of what he said anyway. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Dump Reading (was Re: LSQA shortage)
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Tony Harminc > > [ snip ] > > Naturally I expected a medal from IBM... :-) Why would you expect a medal from someone you've just embarrassed?? :-) -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
UNSUBSCRIBE
Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Dump Reading (was Re: LSQA shortage)
Ed said, > Mark Z was right when he guessed that most of the dumps Chris and I read > are produced by products for which we have the source code. But, in my > case, I certainly don't stop there. I make it a point to analyze (albeit > sometimes just briefly) every dump I send to IBM associated with any PMR > I've opened. And, every once in a while, that analysis comes in handy! True. Having access to the source code helps, but only when the failure is in our own code. When it is down in the bowels of the system, we still have to go dig around and figure out whether it was because of a defect in IBM code or, more likely, that our code did something that left the OS dazed and confused. > IBM has some absolutely amazing dump readers. (Jim Mulder and Nadine > Goldberg have to be at or near the top of the list!) Jim is a GREAT dump reader and he's helped me unravel problems untold times over the years. But I suspect Nadine is actually an alien because she is just freakishly good at dump reading. (See "Men in Black") :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
PLO concurrency (was RE: Help with TCB status)
-Original Message- From: "Craddock, Chris" <[EMAIL PROTECTED]> Sent: 7/6/2006 12:57 PM To: "IBM-MAIN@BAMA.UA.EDU" Subject: Re: Help with TCB status Ed (and Jeff Smith) asked > Are you sure PLO can be used this way? Will the "compare" portion work > against arbitrary values not serialized/updated using PLO? Well now that you mention it, I'm NOT sure. The compare and load functions are supposed to be for following chains that can change while you're looking at them. I had a conversation about PLO with Bob Rogers a long time ago and came away with the impression that the operands were fetched (in the normal way) -before- the comparison was made, so if you got CC=0 then, at least in the compare and load case, you had a point-in-time consistent view which is all that I wanted. I haven't actually used this "trick" anywhere and since it might not actually work the way I thought, I won't use it. I can't blame Bob because I was probably reading between the lines of what he said anyway. CC Greetings, It's quite clear from reading the PoPs that the COMPARE is separated in time from the LOAD. The only thing that makes the whole operation look atomic is holding the hardware lock. So, all CPU must agree on the PLO lock token (R1) and only use PLO for reading or writing (the standard COMPARE-SWAP instructions won't interoperate with PLO). Jeffrey D. Smith Farsight Systems Corporation 24 BURLINGTON DR LONGMONT, CO 80501 303-774-9381 direct 303-709-8153 cell 303-484-6170 fax -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: avgrec/avgblk history ?
That is true for any dataset. If you "create" (allocate space to and write an entry in the VTOC) a dataset but never open it for output, a subsequent step, or even a subsequent job days later, can open that dataset and read it, getting whatever data happens to be on those tracks, with no error indication, unless the reading program happens to get an S013(?) because the blocks are the wrong size, not valid RECFM=V format, etc. Results are unpredictable: one day you will get an ABEND, the next day you will read in unexpected data, and on the third try you will be lucky enough to hit an EOF marker (or empty tracks followed by an EOF marker) right away. An interesting mainframe "hack" would be to write a program that allocated vast quantities of DASD DISP=NEW and then read whatever happened to be there (RECFM=U, of course), looking for "interesting" data. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Veilleux, Jon L Sent: Thursday, July 06, 2006 11:47 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: avgrec/avgblk history ? At one time, and I don't know if it still works this way, if you allocated a temporary dataset with disp=mod,pass and didn't open it in the first step, when you opened it in the second step with disp=mod, it would read the residual data from the work disk at the point where the file was allocated. We ran into this in an ASML proc where the LINK step -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Howards VSAM problem
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Howard Rifkind > > No longer worth while...the box is going to be replace in > favor of blade servers running linux. I was told that this > is the wave of the future. Could be. But if that "blade farm" grows beyond a certain size, they're gonna wish they had a centralized "elevator" in which to store all their "grain" (Insert one of Tim Sipples' evangelicals about z/Linux on z/VM here.) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: avgrec/avgblk history ?
On Thu, 6 Jul 2006 13:39:51 -0500, Paul Gilmartin <[EMAIL PROTECTED]> wrote: >o DISP=MOD,DSN=HLQ.LLQ(&MEMBER) to prevent overwriting an existing member. > I've distributed some JCL using this, and about once a year I get a phone > call about a Sx14 ABEND. Generally, the caller is grateful when I remind > him he was about to overwrite, and renames the existing member for > backup. > I hadn't noticed this before. Thanks, Gil! Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: avgrec/avgblk history ?
Tom, In that case, you may have missed this enhancement in (E)JES Release Information when V4R1 came out: |x.7.1 New Meaning for DISP=NEW for PDS(E) Extract | |In prior releases, two different mechanisms were needed to protect |existing DASD data from overlay by an extract operation. | |Specifying DISP=NEW prevented overlay of an existing data set. The only |way to protect an individual member within an existing partitioned data |set was to specify DISP=MOD, which would result in a B14-04 abend if the |member previously existed. | |This meant that DISP=NEW was the most appropriate way to protect a |sequential data set from overlay while DISP=MOD was the most appropriate |way to protect a member of a PDS(E) from overlay. | |Beginning in this release, DISP=NEW is treated like DISP=MOD for an |existing partitioned data set. Now DISP=NEW can be used to protect both |sequential data sets and PDS(E) members from overlay. Ed Jaffe Tom Marchant wrote: On Thu, 6 Jul 2006 13:39:51 -0500, Paul Gilmartin <[EMAIL PROTECTED]> wrote: o DISP=MOD,DSN=HLQ.LLQ(&MEMBER) to prevent overwriting an existing member. I've distributed some JCL using this, and about once a year I get a phone call about a Sx14 ABEND. Generally, the caller is grateful when I remind him he was about to overwrite, and renames the existing member for backup. I hadn't noticed this before. Thanks, Gil! Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: avgrec/avgblk history ?
Edward Jaffe wrote: Tom, In that case, you may have missed this enhancement in (E)JES Release Information when V4R1 came out: Oops. That was supposed to be sent off-list directly to Tom ... :-[ -- 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: avgrec/avgblk history ?
That is true for any dataset. If you "create" (allocate space to and write an entry in the VTOC) a dataset but never open it for output, a subsequent step, or even a subsequent job days later, can open that dataset and read it, getting whatever data happens to be on those tracks Charles, that is only true for PS datasets, and only on non-SMS volumes. On SMS, allocation of a PS dataset writes an EOF on the first track even if you don't open it. PO datasets write directories. VSAM use the RBA values from the VVR and don't let you read data that doesn't exist -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.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: avgrec/avgblk history ?
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills > Sent: Thursday, July 06, 2006 2:25 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: avgrec/avgblk history ? > > > That is true for any dataset. If you "create" (allocate space > to and write > an entry in the VTOC) a dataset but never open it for output, > a subsequent > step, or even a subsequent job days later, can open that > dataset and read > it, getting whatever data happens to be on those tracks, with no error > indication, unless the reading program happens to get an > S013(?) because the > blocks are the wrong size, not valid RECFM=V format, etc. Results are > unpredictable: one day you will get an ABEND, the next day > you will read in > unexpected data, and on the third try you will be lucky > enough to hit an EOF > marker (or empty tracks followed by an EOF marker) right away. > > An interesting mainframe "hack" would be to write a program > that allocated > vast quantities of DASD DISP=NEW and then read whatever > happened to be there > (RECFM=U, of course), looking for "interesting" data. > > Charles Charles, Remember that for some dataset DSORGs, allocation may do some I/O. In particular, when you define a PDS, the directory is created and formatted. And when you create a file with DSORG=PS (or if it is defaulted via an assigned DATACLAS), then allocation will write an EOF marker (this is new in SMS). If you want avoid this, then I think you'd need to use RECFM=U,DSORG=DA,BLKSIZE=32756 on your allocation request. I'm fairly sure that would result in your program being able to read any residual data. Which, of course, means that in a truly secure environment, RACF should be use to do an "erase" function when the dataset is scratched. This is not NSA-proof, of course, but a simple rewriting of the tracks with, I think, binary zeros on all allocated tracks. That would stop the above. But it is costly in terms of I/O and CPU. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
COBOL Working Storage being reset
I'm trying to help someone upgrade their Cobol code from OS/Cobol to Enterprise Cobol and they've run into a problem I haven't been able to solve (yet). The main program is an Assembler (HLA as I can see 569623400 in the module code) and it calls a number of other programs depending on logic. The particular Cobol programs we're working on is called multiple times. In the working storage section is this definition: 01 UPDATES-SWITCH PIC X VALUE 'N'. 88 NO-UPDATES VALUE 'N'. and the programmer has added these displays to prove the situation: DISPLAY 'UPDATES-SWITCH BEFORE ' UPDATES-SWITCH MOVE 'Y' TO UPDATES-SWITCH. DISPLAY 'UPDATES-SWITCH' UPDATES-SWITCH The results of the display first time through the Cobol program are: UPDATES-SWITCH BEFORE N UPDATES-SWITCHY and is the same for OS/Cobol and Enterprise Cobol. When the Cobol program is OS/Cobol the subsequent displays show: UPDATES-SWITCH BEFORE Y UPDATES-SWITCHY but with Enterprise Cobol we get: UPDATES-SWITCH BEFORE N UPDATES-SWITCHY Control from the Cobol program is returned to the Assembler program via GOBACK. I'm hoping for some suggestions as to why the UPDATES-SWITCH field is being reset to N. I'm still researching and if I find anything myself I'll let the list know. Thanks. Alan Schwartz Assurant Shared Business Services Lead Systems Programmer Phone: 651-361-4758 Fax: 651-361-5625 ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL Working Storage being reset
RENT, REUS on the binder different? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Alan Schwartz Sent: Thursday, July 06, 2006 2:40 PM To: IBM-MAIN@BAMA.UA.EDU Subject: COBOL Working Storage being reset I'm trying to help someone upgrade their Cobol code from OS/Cobol to Enterprise Cobol and they've run into a problem I haven't been able to solve (yet). The main program is an Assembler (HLA as I can see 569623400 in the module code) and it calls a number of other programs depending on logic. The particular Cobol programs we're working on is called multiple times. In the working storage section is this definition: 01 UPDATES-SWITCH PIC X VALUE 'N'. 88 NO-UPDATES VALUE 'N'. and the programmer has added these displays to prove the situation: DISPLAY 'UPDATES-SWITCH BEFORE ' UPDATES-SWITCH MOVE 'Y' TO UPDATES-SWITCH. DISPLAY 'UPDATES-SWITCH' UPDATES-SWITCH The results of the display first time through the Cobol program are: UPDATES-SWITCH BEFORE N UPDATES-SWITCHY and is the same for OS/Cobol and Enterprise Cobol. When the Cobol program is OS/Cobol the subsequent displays show: UPDATES-SWITCH BEFORE Y UPDATES-SWITCHY but with Enterprise Cobol we get: UPDATES-SWITCH BEFORE N UPDATES-SWITCHY Control from the Cobol program is returned to the Assembler program via GOBACK. I'm hoping for some suggestions as to why the UPDATES-SWITCH field is being reset to N. I'm still researching and if I find anything myself I'll let the list know. Thanks. 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: COBOL Working Storage being reset
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Schwartz > Sent: Thursday, July 06, 2006 2:40 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: COBOL Working Storage being reset > > > I'm trying to help someone upgrade their Cobol code from OS/Cobol to > Enterprise Cobol and they've run into a problem I haven't > been able to > solve (yet). The main program is an Assembler (HLA as I can > see 569623400 > in the module code) and it calls a number of other programs > depending on > logic. > > The particular Cobol programs we're working on is called > multiple times. > In the working storage section is this definition: > > 01 UPDATES-SWITCH PIC X VALUE 'N'. > 88 NO-UPDATES VALUE 'N'. > > and the programmer has added these displays to prove the situation: > > DISPLAY 'UPDATES-SWITCH BEFORE ' UPDATES-SWITCH > MOVE 'Y' TO UPDATES-SWITCH. > DISPLAY 'UPDATES-SWITCH' UPDATES-SWITCH > > The results of the display first time through the Cobol program are: > > UPDATES-SWITCH BEFORE N > UPDATES-SWITCHY > > and is the same for OS/Cobol and Enterprise Cobol. When the > Cobol program > is OS/Cobol the subsequent displays show: > > UPDATES-SWITCH BEFORE Y > UPDATES-SWITCHY > > but with Enterprise Cobol we get: > > UPDATES-SWITCH BEFORE N > UPDATES-SWITCHY > > Control from the Cobol program is returned to the Assembler > program via > GOBACK. > > I'm hoping for some suggestions as to why the UPDATES-SWITCH field is > being reset to N. I'm still researching and if I find > anything myself > I'll let the list know. > > Thanks. To avoid this problem, your HLASM program must be Language Environment. The problem is that Enterprise COBOL is LE. When it is invoked from an non-Language Environment program, such as most assembler, then LE reinitializes itself, which means the program's Working Storage is reinitialized. >From "z/OS: Language Environment Programming Guide" Under Language Environment, an application terminates when any of the following conditions occur: ... COBOL's GOBACK statement in a main program ... -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL Working Storage being reset
Is your assembler main program Language Environment-aware (by calling the CEEENTRY macro with MAIN=YES)? If not, then each time the assembler program calls the COBOL program, Language Environment builds a brand new runtime environment for the COBOL program to execute within. This overhead will result in additional CPU cost, as well as the behavior you're seeing. The Assembler main program should be made Language Environment-aware. Check the Enterprise COBOL Migration Guide (GC27-1409) on the LE bookshelf for details. Brian On Thu, 6 Jul 2006 14:39:59 -0500, Alan Schwartz <[EMAIL PROTECTED]> wrote: >I'm hoping for some suggestions as to why the UPDATES-SWITCH field is >being reset to N. I'm still researching and if I find anything myself >I'll let the list know. > >Thanks. > >Alan Schwartz -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Dump Reading (was Re: LSQA shortage)
Long ago when I was an Amdahl SE and there was microfiche, I was involved with a problem that was affecting only one MVS image out of about ten. The system would run out of CSA and have to be IPLed. That was the system that was used by their home-grown TP system that was the order entry application. It turned out that there was an SRM bug that only occurred when running BTAM. It wasn't a very big piece of CSA that was not being freed, but it was a pretty busy system. I wrote a zap to correct the problem and gave it to the sysprog's manager. He asked me if it was a bug in Amdahl code. I told him that it was an MVS bug. He said that he didn't want to put an Amdahl fix on IBM code. I went to the IBM PSR's office, explained to him what the problem was, and gave him the fix. When IBM issued the PTF, it was just about the same as the zap I created. I didn't expect a medal, certainly didn't get one. Didn't even get any acknowledgement, but I got something much better. From that day forward, I always had an excellent relationship with the IBM PSR. Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: COBOL Working Storage being reset
4.1.2 Ending and reentering main programs or subprograms A subprogram is usually left in its last-used state when it terminates with EXIT PROGRAM or GOBACK. The next time the subprogram is called in the run unit, its internal values will be as they were left, except that return values for PERFORM statements will be reset to their initial values. (In contrast, a main program is initialized each time it is called.) There are some cases where programs will be in their initial state: A subprogram that is dynamically called and then canceled will be in the initial state the next time it is called. A program with the INITIAL attribute will be in the initial state each time it is called. Data items defined in the LOCAL-STORAGE SECTION will be reset to the initial state specified by their VALUE clauses each time the program is called. IBM Mainframe Discussion List wrote on 07/06/2006 03:39:59 PM: > I'm trying to help someone upgrade their Cobol code from OS/Cobol to > Enterprise Cobol and they've run into a problem I haven't been able to > solve (yet). The main program is an Assembler (HLA as I can see 569623400 > in the module code) and it calls a number of other programs depending on > logic. > The particular Cobol programs we're working on is called multiple times. > In the working storage section is this definition: > 01 UPDATES-SWITCH PIC X VALUE 'N'. > 88 NO-UPDATES VALUE 'N'. > and the programmer has added these displays to prove the situation: > DISPLAY 'UPDATES-SWITCH BEFORE ' UPDATES-SWITCH > MOVE 'Y' TO UPDATES-SWITCH. > DISPLAY 'UPDATES-SWITCH ' UPDATES-SWITCH > The results of the display first time through the Cobol program are: > UPDATES-SWITCH BEFORE N > UPDATES-SWITCH Y > and is the same for OS/Cobol and Enterprise Cobol. When the Cobol program > is OS/Cobol the subsequent displays show: > UPDATES-SWITCH BEFORE Y > UPDATES-SWITCH Y > but with Enterprise Cobol we get: > UPDATES-SWITCH BEFORE N > UPDATES-SWITCH Y > Control from the Cobol program is returned to the Assembler program via > GOBACK. > I'm hoping for some suggestions as to why the UPDATES-SWITCH field is > being reset to N. I'm still researching and if I find anything myself > I'll let the list know. > Thanks. > Alan Schwartz - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. 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: COBOL Working Storage being reset
Alan Schwartz wrote: I'm trying to help someone upgrade their Cobol code from OS/Cobol to Enterprise Cobol and they've run into a problem I haven't been able to solve (yet). The main program is an Assembler (HLA as I can see 569623400 in the module code) and it calls a number of other programs depending on logic. The particular Cobol programs we're working on is called multiple times. In the working storage section is this definition: 01 UPDATES-SWITCH PIC X VALUE 'N'. 88 NO-UPDATES VALUE 'N'. and the programmer has added these displays to prove the situation: DISPLAY 'UPDATES-SWITCH BEFORE ' UPDATES-SWITCH MOVE 'Y' TO UPDATES-SWITCH. DISPLAY 'UPDATES-SWITCH' UPDATES-SWITCH The results of the display first time through the Cobol program are: UPDATES-SWITCH BEFORE N UPDATES-SWITCHY and is the same for OS/Cobol and Enterprise Cobol. When the Cobol program is OS/Cobol the subsequent displays show: UPDATES-SWITCH BEFORE Y UPDATES-SWITCHY but with Enterprise Cobol we get: UPDATES-SWITCH BEFORE N UPDATES-SWITCHY Control from the Cobol program is returned to the Assembler program via GOBACK. I'm hoping for some suggestions as to why the UPDATES-SWITCH field is being reset to N. I'm still researching and if I find anything myself I'll let the list know. Thanks. Alan Schwartz Assurant Shared Business Services Lead Systems Programmer Phone: 651-361-4758 Fax: 651-361-5625 1. Is the Assembler code LE-conforming? 2. Does the compile proc for the Enterprise compiler use different options from the OS/VS compiler? In particular, consider RENT and THREAD 3. Is it the same program each time or do you have Enterprise COBOL version and an OS/VS version? Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Help with TCB status
On Thu, 6 Jul 2006 14:57:32 -0400 "Craddock, Chris" <[EMAIL PROTECTED]> wrote: :>Ed (and Jeff Smith) asked :>> Are you sure PLO can be used this way? Will the "compare" portion work :>> against arbitrary values not serialized/updated using PLO? :>Well now that you mention it, I'm NOT sure. The compare and load :>functions are supposed to be for following chains that can change while :>you're looking at them. I had a conversation about PLO with Bob Rogers a :>long time ago and came away with the impression that the operands were :>fetched (in the normal way) -before- the comparison was made, so if you :>got CC=0 then, at least in the compare and load case, you had a :>point-in-time consistent view which is all that I wanted. I haven't :>actually used this "trick" anywhere and since it might not actually work :>the way I thought, I won't use it. I can't blame Bob because I was :>probably reading between the lines of what he said anyway. My understanding of PLO is that it only serializes with the specified lock number/address. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL Working Storage being reset
Exactly. Been in this section. The subprogram has no 'cancel' and there is no LOCAL-STORAGE-SECTION. I haven't seen anything proving the INITIAL attribute one way or the other. Alan Schwartz Assurant Shared Business Services Lead Systems Programmer Phone: 651-361-4758 Fax: 651-361-5625 Kirk Talman <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 07/06/2006 02:56 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Re: COBOL Working Storage being reset 4.1.2 Ending and reentering main programs or subprograms A subprogram is usually left in its last-used state when it terminates with EXIT PROGRAM or GOBACK. The next time the subprogram is called in the run unit, its internal values will be as they were left, except that return values for PERFORM statements will be reset to their initial values. (In contrast, a main program is initialized each time it is called.) There are some cases where programs will be in their initial state: A subprogram that is dynamically called and then canceled will be in the initial state the next time it is called. A program with the INITIAL attribute will be in the initial state each time it is called. Data items defined in the LOCAL-STORAGE SECTION will be reset to the initial state specified by their VALUE clauses each time the program is called. ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL Working Storage being reset
1. The Assembler code is not LE conforming. Much consists of proprietary type macros (CKSYSTEM, CKDEBUG, CKENTER, CKCOMSHD, CKCALL CKCFNCTR) for example. 2. Compiler options have some differences as expected. The Enterprise Cobol options do have RENTand NOTHREAD 3. The source is exactly the same between runs. Just changing invoking program name. Alan Schwartz Assurant Shared Business Services Lead Systems Programmer Phone: 651-361-4758 Fax: 651-361-5625 Steve Comstock <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 07/06/2006 02:58 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Re: COBOL Working Storage being reset 1. Is the Assembler code LE-conforming? 2. Does the compile proc for the Enterprise compiler use different options from the OS/VS compiler? In particular, consider RENT and THREAD 3. Is it the same program each time or do you have Enterprise COBOL version and an OS/VS version? Kind regards, -Steve Comstock ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL Working Storage being reset
Brian (and John), I've been reading the Cobol and LE books for ILC information. In my z/OS 1.7 LE Writing ILC Applications topic 14.3 there's "Table 61. What Occurs When Non-Language Environment-Conforming Assembler Invokes an HLL Main". for invoking options LOAD and BALR, when LE is up, it says "CEE393 is signaled. You cannot LOAD and BALR a main routine under Language Environment. However, in COBOL, this is supported because the COBOL program would be a subroutine, not a main." Perhaps I misinterpreted this to mean the Assembler was ok as was. Alan Brian Peterson <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List 07/06/2006 02:54 PM Please respond to IBM Mainframe Discussion List To IBM-MAIN@BAMA.UA.EDU cc Subject Re: COBOL Working Storage being reset Is your assembler main program Language Environment-aware (by calling the CEEENTRY macro with MAIN=YES)? If not, then each time the assembler program calls the COBOL program, Language Environment builds a brand new runtime environment for the COBOL program to execute within. This overhead will result in additional CPU cost, as well as the behavior you're seeing. The Assembler main program should be made Language Environment-aware. Check the Enterprise COBOL Migration Guide (GC27-1409) on the LE bookshelf for details. Brian ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: COBOL Working Storage being reset
It's been a while, but I thought there were global options that get set when the product is installed, one of which affects how to treat working storage. I also thought that you could create a separate set of options that could be used to override the global ones (on a per job basis). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SHOXzOS 712
Greetings Roland,
I am trying to run SHOWZOS 712 and got the following:
IEA995I SYMPTOM DUMP OUTPUT 933
SYSTEM COMPLETION CODE=0C4 REASON CODE=0011
TIME=11.52.46 SEQ=55689 CPU= ASID=00F2
PSW AT TIME OF ERROR 078D1000 80066C30 ILC 6
INTC 11
ACTIVE LOAD MODULE ADDRESS=000659A0
OFFSET=1290
NAME=DSNACAF
DATA AT PSW 00066C2A - A2A94780 B414D509
8000A396
GR 0: 00BF4160 1: 000679A4
2: 0005A180 3:
4: 0005A180 5: 0004
6: 80064930 7: 0009
8: 19000101 9: 0001
A: 0006785B B: 8006685C
C: 0002C928 D: 0002C928
E: 00067CDC F: 0007
END OF SYMPTOM DUMP
IEA995I SYMPTOM DUMP OUTPUT 934
SYSTEM COMPLETION CODE=0C4 REASON CODE=0004
TIME=11.52.46 SEQ=55690 CPU= ASID=00F2
PSW AT TIME OF ERROR 078D2000 A30A63CC ILC 4
INTC 04
ACTIVE LOAD MODULE ADDRESS=2307F0F0
OFFSET=000272DC
NAME=ISFINIT
DATA AT PSW 230A63C6 - D00C9600 40005120
6002A7E5
GR 0: 0028 1:
2: 0006785B 3:
4: 0006785B 5: 0004
6: A30961CA 7: 0009
8: 00FCED98 9: 00AE5298
A: 0006785B B: 2307F10C
C: 0002C928 D: 0005A070
E: A30810FC F: 230A6370
END OF SYMPTOM DUMP
IEA995I SYMPTOM DUMP OUTPUT 935
SYSTEM COMPLETION CODE=0C4 REASON CODE=0004
TIME=11.52.46 SEQ=55691 CPU= ASID=00F2
PSW AT TIME OF ERROR 078D2000 A30A63CC ILC 4
INTC 04
ACTIVE LOAD MODULE ADDRESS=2307F0F0
OFFSET=000272D
NAME=ISFINIT
DATA AT PSW 230A63C6 - D00C9600 40005120
6002A7E5
GR 0: 0028 1:
2: 0006785B 3:
4: 0006785B 5: 0004
6: A3096268 7: 0009
8: 00FCED98 9: 00AE5298
A: 0006785B B: 2307F10C
C: 0002C928 D: 0005A070
E: A3081240 F: 230A6370
END OF SYMPTOM DUMP
Numerous ISFINIT followed this one.
I want to run it unauthorized, and here is the
invocation REXX EXEC:
address ISPEXEC
"LIBDEF ISPLLIB DATASET
ID('SYS2.SHOWZOS.V7R1M2.LINKLIB') STACK"
"SELECT PGM(SHOWZOS) NEWAPPL(SHW) PASSLIB"
"LIBDEF ISPLLIB"
exit
I did not do an assembly, just using the files from
cbttape.org.
Please advise...
Michael
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.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: COBOL Working Storage being reset
Alan Schwartz wrote: Brian (and John), I've been reading the Cobol and LE books for ILC information. In my z/OS 1.7 LE Writing ILC Applications topic 14.3 there's "Table 61. What Occurs When Non-Language Environment-Conforming Assembler Invokes an HLL Main". for invoking options LOAD and BALR, when LE is up, it says "CEE393 is signaled. You cannot LOAD and BALR a main routine under Language Environment. However, in COBOL, this is supported because the COBOL program would be a subroutine, not a main." Perhaps I misinterpreted this to mean the Assembler was ok as was. Alan The call is supported, but as that table also points out, an Initial enclave is created. This is what tells you the working-storage is created fresh each time, since the module must be loaded each time. (There's more to it but that's enough to cause the symptoms you see.) To get the COBOL module in its last-used state each time you call, you will have to make the Assembler program LE-conforming. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
Paul, I'm taking up Charles's challenge to spawn a new thread concerning DISP=MOD but your contribution is closer to the point on which I wanted to comment. I used to use DISP=(MOD,DELETE) with PGM=IEFBR14 in typically the first job step in order to dispose of a previous instance of a data set which may or may not exist. I then allocated the data set in the following step with DISP=OLD. I used to do this for data sets which may or may not be used in that job step and so the allocation was a small primary, say, 1 track, and a large secondary, say 50 tracks with RLSE added for tidiness. There is an apparent problem with this technique in that it might convert a started task procedure with one step into one with multiple steps. This brings us to SYST. Back in February, I asked about the consequences of removing SYST from a SCHEDxx entry which might have been mandated by a product install. Would removing it create a situation incompatible with running in production? I had been doing it for years on test systems without evident ill effect. Naturally TIME=1440 needs to be added to the EXEC statement but was that really all? After a number of responses that did indeed seem to be the case. Thus, if you want to use a DISP=MOD "trick" and that creates the need to add a job step to a started task procedure, you can always remove SYST in the SCHEDxx member if present for your program while at the same time ensuring that TIME=1440 to the EXEC statement. Going back to whether or not the data set exists, it may be that, if a dump is taken, it is printed off and that job deletes the data set as something just using precious space that is no longer needed. There may be other reasons why such essentially temporary data sets may or may not be left lying around. I have some lecture notes where I describe this for a VTAM/NET started task procedure so I may as well provide them as an example of what I was talking about above: //NET PROC //* //IEFBR14 EXEC PGM=IEFBR14 //NCPDUMP DD DSN=USER.NCPDUMP,DISP=(MOD,DELETE), // VOL=REF=SYS1.PARMLIB,SPACE=(TRK,1) //* //NET EXEC PGM=ISTINM01,TIME=1440 //STEPLIB DD DSN=SYS1.SSPLIB,DISP=SHR //VTAMLST DD DSN=USER.VTAMLST,DISP=SHR //VTAMLIB DD DSN=USER.VTAMLIB,DISP=SHR //DD DSN=SYS1.VTAMLIB,DISP=SHR //NCPLOAD DD DSN=USER.NCPLOAD,DISP=SHR //NCPDUMP DD DSN=USER.NCPDUMP,DISP=(NEW,KEEP), // VOL=REF=SYS1.PARMLIB,SPACE=(TRK,(1,50),RLSE), // DCB=(RECFM=F,LRECL=512,BLKSIZE=512) I see this is very old since I seem not to have updated it for a possibly larger NCP dump record size - just in case anyone wanted to mention that point. Another point about my example is that it is oriented to a started task procedure which is started in the morning and closed down sometime in the evening - which, certainly for VTAM, aligns it with rather outdated concepts for running systems - again just in case that thought was bothering anyone reading this. Chris Mason - Original Message - From: "Paul Gilmartin" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Thursday, 06 July, 2006 8:39 PM Subject: Re: avgrec/avgblk history ? > > That said, my most frequent uses of MOD are for its collateral effects: > > o Conditionally create a data set in an IEFBR14 step with DISP=(MOD,CATLG), > then write it in a subsequent step with DISP=OLD. > > o Conditionally delete a data set with DISP=(MOD,DELETE). > -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: COBOL Working Storage being reset
Alan, I suggest that you add CALL ILBOSTP0 at the beginning of the assembler program (make sure R13 is clean). This is the simplest way to create an enclave and tell the COBOL module that it's a sub-program, not a main program. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ mailto:[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: Howards VSAM problem
Yes John, but go and try to tell them that. IBM's BC z manchine can be gotten for some where in the $100k area, real damm cheap. And that would put the blades to sleep for a long to come. All their so called applications requiring linux would run fine on the z and then we could take hardware issues out of the picture and be left with junk software. Go figure. "Chase, John" <[EMAIL PROTECTED]> wrote: > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Howard Rifkind > > No longer worth while...the box is going to be replace in > favor of blade servers running linux. I was told that this > is the wave of the future. Could be. But if that "blade farm" grows beyond a certain size, they're gonna wish they had a centralized "elevator" in which to store all their "grain" (Insert one of Tim Sipples' evangelicals about z/Linux on z/VM here.) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail Beta. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
In a recent note, Chris Mason said: > Date: Thu, 6 Jul 2006 22:55:44 +0200 > > I used to use DISP=(MOD,DELETE) with PGM=IEFBR14 in typically the first job > step in order to dispose of a previous instance of a data set which may or > may not exist. I then allocated the data set in the following step with > DISP=OLD. I used to do this for data sets which may or may not be used in > that job step and so the allocation was a small primary, say, 1 track, and a > large secondary, say 50 tracks with RLSE added for tidiness. > > There is an apparent problem with this technique in that it might convert a > started task procedure with one step into one with multiple steps. This > brings us to SYST. > I deliberately [over]simplified my example. When I wish either to create a new data set, or re-use the existing one, I often use the following to avoid adding a job step: //STEP EXEC PGM=IEBGENER //ALLOC DD DISP=(MOD,CATLG),UNIT=&DASD,DSN=...,SPACE=... //SYSUT2DD DISP=OLD,DSN=*.ALLOC,VOL=REF=*.ALLOC,UNIT=&DASD Specifying VOL (with a referback) and UNIT permits accessing DSN before it is catalogued. Would similar work for deleting and creating in a single job step: //STEP EXEC PGM=IEBGENER //ALLOC DD DISP=(MOD,DELETE),UNIT=&DASD,DSN=...,SPACE=... //SYSUT2DD DISP=OLD,DSN=*.ALLOC,UNIT=&DASD ...? I believe the ALLOC data set is uncatalogued before SYSUT2 is catalogued (order of DD statements?). Of course this requires an elegible storage volume in addition to the one used by the ALLOC DD. If responses are vague or contradictory I'll try a test. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
What AMDAHL boxes support PLO instruction?
Greetings, Anyone out there know whether any AMDAHL (32-bit) boxes support the PLO instruction? If so, which models? Jeffrey D. Smith Farsight Systems Corporation 24 BURLINGTON DR LONGMONT, CO 80501 303-774-9381 direct 303-709-8153 cell 303-484-6170 fax -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: What AMDAHL boxes support PLO instruction?
Jeffrey D. Smith wrote: Anyone out there know whether any AMDAHL (32-bit) boxes support the PLO instruction? If so, which models? PLO was part of the first architectural level set. It was required for OS/390 V2R10. Any machine certified to run OS/390 V2R10 has PLO. -- 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: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
In a recent note, Edward Jaffe said: > Date: Thu, 6 Jul 2006 12:33:43 -0700 > | > |This meant that DISP=NEW was the most appropriate way to protect a > |sequential data set from overlay while DISP=MOD was the most appropriate > |way to protect a member of a PDS(E) from overlay. > | On-topic and new (as this is to me) information ought always to be welcome on this list. > |Beginning in this release, DISP=NEW is treated like DISP=MOD for an > |existing partitioned data set. Now DISP=NEW can be used to protect both > |sequential data sets and PDS(E) members from overlay. > This change is unwelcome; it merely introduces degeneracy. Formerly a programmer who wished either the function of DISP=NEW or DISP=MOD could choose the one more suitable. Making this change merely removes the former (possibly useful) distinct behavior of DISP=NEW while adding no new function. OTOH, I would be overjoyed to see the semantic of DISP=(OLD,DELETE),DSN=HLQ.LLQ(MEMBER) changed to the more intuitive deletion of only MEMBER, the object clearly named, rather than the counterintuitive deletion of the entire library. If I intend to delete the entire library, I can omit the (MEMBER) name. It's the way the TSO DELETE command works; JCL ought to be consistent. (Bad history be damned!) -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
Paul Gilmartin wrote: This change is unwelcome; Not according to our customers! :-) -- 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: avgrec/avgblk history ?
And then theres the thread started by saying that 3 more threads will be started. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee Wisconsin 414-475-7434 - Original Message - From: "Charles Mills" <[EMAIL PROTECTED]> Subject: Re: avgrec/avgblk history ? P.S. This will inevitably start three new threads: one a nostalgia thread on "I remember when PCP Rel. 12 had a bug in DISP=MOD," one on "most creative uses for DISP=MOD" (and then why some alternative approach is MUCH better), and one on "why DISP=MOD is vastly superior to (or alternatively, vastly inferior to) UNIX open append" . -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: avgrec/avgblk history ?
I used to use DISP=MOD solely for collecting SMF data - modding the daily tape on the end of the monthly SMF tapes. It was mostly reliable, but when it failed, which it did a few times over the years, you lost a good chunk of your SMF data for the month. I eventually changed to keeping a weeks worth of tapes, which I merged into a weekly tape. At the end of the month I merged them into a monthly, that we saved for about 14 months. I don't think that process ever failed. I think the newer tape drives probably fail a lot less on DISP=MOD. I noticed that when we went from 3420 to 3480 tapes, and again when we converted to 3490s. I'm sure the 3590s are even better. I don't think we even used our monthly SMF tapes for the last 3 or 4 years. When our datacenter closed in April, we scrapped all off the tapes. We couldn't process them without a lot of expense. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee Wisconsin 414-475-7434 - Original Message - From: "Paul Gilmartin" <[EMAIL PROTECTED]> Subject: Re: avgrec/avgblk history ? This is the first I have heard of unreliability of DISP=MOD. Is that the consensus of readers here? -- gil -- StorageTek -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
In a recent note, Edward Jaffe said: > Date: Thu, 6 Jul 2006 15:15:35 -0700 > > > This change is unwelcome; > > Not according to our customers! :-) > Why would anyone welcome a change that merely diminishes function? (Of course I'm free to make a private assessment of your customers' cognitive capacities that you could never utter publicly.) I checked your website; (E)JES is your product; I had been unaware of that (or had forgotten). I'm accustomed to getting a JCL error when I specify DISP=NEW and the data set preexists. Do you avoid this by making Type 1 changes to allocation, or is the "DISP=NEW" an operand of an (E)JES subcommand rather than a JCL DD statement operand? And does there remain a construct for specifying that the programmer requires a new library, not merely a new member of an existing library? -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
In a recent note, Eric N. Bielefeld said: > Date: Thu, 6 Jul 2006 17:28:00 -0500 > > I think the newer tape drives probably fail a lot less on DISP=MOD. I > noticed that when we went from 3420 to 3480 tapes, and again when we > converted to 3490s. I'm sure the 3590s are even better. > Was the cause ever analyzed? It would have to be something like false detection of a file trailer label, implausible as that seems to me. Hard problem to re-create. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isn't DISP=MOD wonnderful? (was avgrec/avgblk history ?)
Paul Gilmartin wrote: Why would anyone welcome a change that merely diminishes function? (Of course I'm free to make a private assessment of your customers' cognitive capacities that you could never utter publicly.) Paul, I accidentally sent an e-mail to the list that was intended to go directly (off-list) to Tom Marchant. I don't really have time right now to provide all of the background you would need to understand how this is used and in what context. Suffice to say that the customers that requested (and gladly received) this enhancement were in no way suffering from diminished cognitive capacity. They knew what they were asking for, we agreed it was a valuable enhancement, and it resulted in no loss of function whatsoever. It has nothing to do with how the DISP= keyword is treated in JCL. -- 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: APPC admin utility
Jim, In principle, I'm pretty sure what you need to know concerning the use of program ATBSDFMU is contained in section 10.5.4, "Controlling User Access to TP Profiles and Side Information on MVS" of the z/OS MVS Planning: APPC/MVS Management manual: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2C430/CCONTENTS Now I guess the problem is knowing how to map what IBM says you need to do for RACF to what you need to do for ACF2. I did some consultancy work a while back and the customer with whom I worked was a non-RACF user. Fortunately there was a quiet, charming man who took any security request specified in RACF terms, calmly converted it to whatever was necessary for the customer's security product and set me on my way as a happy user since I knew it would work - assuming my RACF-style input was correct, of course. Perhaps this is the real problem. Please post again if you cannot work it out. Perhaps someone who has worked through security with the APPC/MVS data sets recently will be able to help you out. I doubt it will be me since I sorted this issue out - with RACF, of course - many years ago. At this point I was about to hit send but I thought I might as well check. Because I found myself helping a visitor out with setting up APPC/MVS 20 or more years ago, I packaged up the necessary files in case another visitor came along with the same need - I can't recall whether on not anyone did. Just now checking, I found what I think is my complete RACF file. I expect I kept it in that form because it would be too much work to split out what was specifically APPC/MVS. The RACF file is for a set of 8 essentially identical education/test systems with a set of users for student use oriented purely to principally SNA networking - so it's not that big. Fortunately - self-protection in fact - I have commented it extensively. If you think it might help - you'll still need to "translate" from RACF to ACF2 - I'll send it directly. Please let me know. Chris Mason - Original Message - From: "Jim Nagy" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Thursday, 06 July, 2006 8:00 PM Subject: Re: APPC admin utility > we are able to get rid of the sys1 error by writing a rule for that, but > there is more to appc admin. that we need to write > That is what I need help with. > > Thanks > > Jim Nagy > Software Product Management > 4-6136Internal > 412-544-6136 -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Help with TCB status
> Probably better to just use the TCB pointer chains while holding > the local lock. You've piqued my interest ... Which TCB chain? Where's its anchor and next chain pointer? Does this chain contain only dispatchable TCB? Currently I run the TCB chain starting from job step TCB and moving forward via the TCBTCB field (while the local lock is held). I check TCBPNDSP, TCBRBWF, and WEBPaused to determine if the TCB is waiting. If not then if TCBACTIV is on I assume it's active. As I've discovered TCBACTIV doesn't give an accurate picture of the TCB's state. Thanks, Vic -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Help with TCB status
> If there isn't a cpu available, or if the task isn't at the head of the > next-to-be-dispatched web queue, then its not going to run. Being > non-dispatchable is a deal breaker, but being dispatchable only means > that you're eligible to run "some time". What points to the "next-to-be-dispatched web queue"? Thanks, Vic -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: avgrec/avgblk history ?
I used to use DISP=MOD solely for collecting SMF data - modding the daily tape on the end of the monthly SMF tapes. It was mostly reliable, but when it failed, which it did a few times over the years, you lost a good chunk of your SMF data for the month. One of the problems with MOD for SMF data is that SMF data is RECFM=VBS, spanned. This means that almost every block (except the first and last written) will be spanned, containng the end of one logical record or the beginning of the next, or both. If the last write to the tape was terminated prematurely or got an I/O error on WRITE, or an I/O error reading back, then when reading the tape you can get S002 abends because spanning errors. Back when I worked for a end-user site, I once spent two days writing custom programs to recover from such an error. When I came to Innovation, my first assignment was FATAR, our tape copy/recovery utility, and one of the first functions I added was identification and recovery from VBS spanning errors. The unfortunate part was that the errors were unnecessary. SMF data can be changed to RECFM=VB,LRECL=32756,BLKSIZE=32760 when copying it, avoiding any spanning problems. -- Bruce Black Senior Software Developer Innovation Data Processing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
