BLKSIZE=0
Charles Mills wrote: 1. It IS on SMS DASD. This is not a theoretical problem -- it happens in real life. The problem is ***not*** with DS1LSTAR or EOF markers. The problem is that the BLKSIZE in the DSCB is zero, QSAM picks that up, puts it in a CCW, falls on its face, and diagnoses the situation with a message that it takes a CCW expert to decode -- rather than diagnosing an easily diagnosable situation with a simple explanation. Is this a (relatively) new problem? As far as I know, OS/360 didn't allow BLKSIZE=0 so this should not happen. At some time later, the ability to specify BLKSIZE=0 was added, along with this problem. Also, is it still possible to open a new data set and read the existing data on the tracks? I know OS/360 would do it, but security requirements have changed since then. (I do remember once having the link editor read some data into SYSLIN that my program never wrote, and then processing it as control cards.) -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: BLKSIZE=0
On Mon, 22 Jan 2007 00:12:34 -0800, glen herrmannsfeldt [EMAIL PROTECTED] wrote: Also, is it still possible to open a new data set and read the existing data on the tracks? -- glen It was certainly the case under XA (2.2.3 IIRC), when I encountered the same issue. Steve O. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: ADRDSSU and AWS
On Fri, 19 Jan 2007 09:41:50 -0600, Sebastian Welton [EMAIL PROTECTED] wrote: Have you tried just using IEBGENER? I know it sounds silly but I create a full disk backup using ADRDSSU and then convert it to AWS format. To restore it I then just use IEBGENER to copy the AWS file to a sequential dataset on disk and then use ADRDSSU to restore it. Sorry Seb, but it does sound silly. No offence intended, but I don't suppose that IEBGENER can process AWS headers. Am I right in thinking you run a Flex-ES system? Flex-ES can handle AWS files, so if you IEBGENER off an AWS FakeTape(tm) it will get translated to blocks that IEBGENER is able to re-block. I run a Flex-ES system so I can do this at home, but I want to take dumps of a test zOS 1.7 system to our datacentre in Bavaria where there is a Z box I can use for testing (IBM will not allow FSI to give me 64 bit support). Maybe I CAN take 46 cartridges in my luggage but it would be a lot easier to take two DVD's containing zipped AWS images of the tapes. But then what do I do with them? I tried overriding the blocksize on the backups to 32760 which can be processed by any utility, but that doubled the elapsed time of the backups. As a last restort I guess I can COPYDUMP the tape to a 32760 disk file and FTP that to a PC, zip it and burn it with no AWS conversion, but it would require an awful lot of disk space. Besides, I have this AWS tape archive system all setup that I would like to ensure is general purpose, so I have to find some way to restore an AWS copy of a backup. Best candidate at the moment seems to be Sam Golob's VTT utilities off file 533 of the CBT tape. Has anyone used this successfully to restore a DfDSS backup? Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: AOPBATCH Continuation character
ln: FSUM6245 link to target \ failed: EDC5111I Permission denied. db2jcc_license_cisuz.jar: FSUM7351 not found IIRC, it's the shell, not AOPBATCH, that deals with continuation characters. Try a backslash at the end of the line - although I'm not sure how this will translate with fixed 80 column input - e.g. ln -s $/usr/lpp/db2/db2810/jcc/classes/db2jcc.jar \ db2jcc.jar; It is the back slash alright and it is the shell that is dealing with it. But if your input is fixed length (and it tends to be if it is instream data in a JCL...) then the backslash has to go in exactly the 80th position. Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: AOPBATCH Continuation character
But if your input is fixed length (and it tends to be if it is instream data in a JCL...) then the backslash has to go in exactly the 80th position. That is: the exact last position of the input record (whatever the LRECL is). Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Master console EXECs
On 1/21/2007 7:50 PM, Paul Gilmartin wrote: Grrr. Why can't SYSTSPRT be directed to operator's console? Why did the designers so abandon orthogonality? I don't think they did. Orthogonality would apply if you -could- direct SYSTSIN to the console, but not SYSTSPRT. As you can not direct SYSTSIN to the console, orthogonality it preserved. Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RMF Spreadsheet reporter - why is FTP deleting report listings
I'm trying to setup the RMF Spreadsheet reporter (V5.2.2) and it works fine the first time, but when I try to generate subsequent working sets it fails. Rather than retrieving the listing, which is successfully created on the host, it deletes it instead: SENT: USER P390 331 Send password please. SENT: PASS (*hidden*) 230 P390 is logged on. Working directory is P390.. SENT: SYST 215 MVS is the operating system of this server. FTP Server is running on z/OS. SENT: PWD 257 'P390.' is working directory. SENT: CWD 'SMFDUMP.RMF.SR' 250 SMFDUMP.RMF.SR. is the working directory name prefix. SENT: PWD 257 'SMFDUMP.RMF.SR.' is working directory. SENT: site retpd 200 SITE command was accepted SENT: site autorecall 200 SITE command was accepted SENT: DELE 'SMFDUMP.RMF.SR.D022.T113157.LISTING' 250 SMFDUMP.RMF.SR.D022.T113157.LISTING deleted. SENT: QUIT 221 Quit command received. Goodbye. Any idea why this is happening and how I can stop it. The first time I use the tool it does a RETR and works fine. Thanks in advance, William The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you are not the intended addressee please contact the sender and dispose of this e-mail. 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: how to introduce change to USSTAB
Ted Thanks for the correction. I took Mark Zelden's reference to LNKLST and added xx without thinking about the alternative.[1] Having now tried to be sure by checking the manuals I see that LNKLST is often used as an abbreviation for linklist and that, as you point out, PROGxx is the recommended way to define the linklist. It even reminds me that I converted all my education/test virtual MVSs from LNKLSTxx to PROGxx, very probably the MVS release PROGxx appeared, because I liked to keep up to date. The reason for the delay in responding - not that a response was obligatory - is that I decided I had to do some research in order to see whence Dr No was getting his response to your post - and, in essence, I failed.[2] I have discovered that it is possible to define which libraries make up the set managed by the LLA facility using the CSVLLSxx member of SYS1.PARMLIB. Thus it is possible that, for example, a partitioned data set containing the USS module which is *not* in the linklist could be identified in the CSVLLAxx member and so, in order to ensure that the new USS module was seen, it would be necessary to enter the MODIFY LLA,REFRESH command. It is also possible that, by use of the CSVLLAxx member, partitioned data sets in the linklist can be removed from being managed by the LLA facility and so, in order to ensure that the new USS module was seen, assuming that the USS module was stored in such a partitioned data set, it would *not* be necessary to enter the MODIFY LLA,REFRESH command. However having a partitioned data set in the linklist not managed by the LLA facility appears to be something that would happen only as part of some maintenance sequence and would not apply generally. So, I would like to suggest that the flat in it's flat wrong is, itself flat wrong. I would have preferred a comment along the lines of Not necessarily, even substituting PROGxx for LNKLSTxx. Please see what you can do with CSVLLAxx.[3] I would even not insist absolutely on the Please. It would appear Dr No has gone off the rails - I'm not sure I've been participating in this list long enough to add the adverb finally. There's also the unusual employment in list exchanges of this type of the third person singular. This looks like a case of If I can catch him once upon the hip, I will feed fat the ancient grudge I bear him. But I mustn't be entirely negative over Dr No's contribution. Despite the typical exhaustion such interventions can cause, my research unearthed the LLACOPY call. If such a call were used during VARY OBEYFILE processing whenever modules such as the USS modules are referenced, maybe there would be no need to remind the creator of a new USS module to concern him/herself with MODIFY LLA,REFRESH. I have run this suggestion up the IBMTCP-L list flagpole ... LLACOPY and VARY OBEYFILE, 17 Jan. Incidentally, Mark was very right to insist that the linklist should be considered. Under USS table customization: in section 2.2.1.10.2, Using the Telnet USS and INTERPRET support, in z/OS Communications Server IP Configuration Guide, we find the sentence The tables must reside in a data set that is in the system's linklist or is in the STEPLIB statement of the TCP/IP startup procedure. Thus, if the original poster, Judy Ellis, was going by the manual, she may well have been using a partitioned data set in the linklist. Chris Mason [1] FWIW, there's a similar error in the documentation. In section 1.6.1, LLA and Module Search Order under 1.6, Improving Module Fetch Performance With LLA in z/OS V1R8.0 MVS Initialization and Tuning Guide, we find 6. SYS1.LINKLIB and libraries concatenated to it through the LNKLSTxx member of parmlib. as the last item listed after When a program requests a module, the system searches for the requested module in various system areas and libraries, in the following order:. I may be guilty but I'm in good company. g [2] The research took in the following: z/OS V1R8.0 MVS Initialization and Tuning Guide 1.4.5.1 The Search Order the System uses for Programs 1.6 Improving Module Fetch Performance With LLA z/OS V1R8.0 MVS Initialization and Tuning Reference 21.0 Chapter 21. CSVLLAxx (library lookaside (LLA) list) 59.0 Chapter 59. LNKLSTxx (LNKLST concatenation) 67.0 Chapter 67. PROGxx (Authorized program list, exits, LNKLST sets and LPA) Did I miss something? [3] Using a CSVLLAxx member even includes the possibility to use MODIFY LLA, UPDATE=xx so that, with a customised CSVLLAxx member, it would be possible to limit the refresh to an individual module, the screwdriver approach. Perhaps that's what I was supposed to have suggested in place of MODIFY LLA,REFRESH, the sledgehammer approach. Chris Mason - Original Message - From: Ted MacNEIL [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Thursday, 04 January, 2007 8:21 AM Subject: Re: how to introduce change to USSTAB If you are storing your USS table load module in a partitioned data
Re: Jobs and the initiators they run in
NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. I wanted to let everyone know that, thanks to Barry Merrill's note below, I was able to come up with a way to track what initiator a job runs in. It does require the use of MXG because Barry's IEFU84 exit is part of MXG, but it works great! As you can tell from his note, he assumes familiarity with MXG. Since it was a private note to me he was right. For those of you not familiar with MXG, he is referring to member IEFU84 in SOURCLIB. Jim Horne Lowe's Companies, Inc. Barry Merrill wrote: Member IEFU84 is the SMF Exit Code to add Initiator Name and Number to the SMF 30 Subtype 1, and member VMAC30 will then pick that information up. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 is command reject trying to tell me?
Charles Now that we've got the EOF issue out of the way, I imagine you are preaching to the converted here. Why not just take the matter up with your friendly IBM representative - who might find his customer satisfaction affected if there's not a logical response to your concern. Chris Mason - Original Message - From: Charles Mills [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, 22 January, 2007 2:27 AM Subject: Re: What is command reject trying to tell me? One more time: 1. It IS on SMS DASD. This is not a theoretical problem -- it happens in real life. The problem is ***not*** with DS1LSTAR or EOF markers. The problem is that the BLKSIZE in the DSCB is zero, QSAM picks that up, puts it in a CCW, falls on its face, and diagnoses the situation with a message that it takes a CCW expert to decode -- rather than diagnosing an easily diagnosable situation with a simple explanation. 2. It's a very specific situation. The dataset is not allocated by a user. It's allocated by a cooperating (semi-cooperative?) automated process -- so Gil's point is correct, but does not apply in my specific situation. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Arthur T. Sent: Sunday, January 21, 2007 5:14 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: What is command reject trying to tell me? On 21 Jan 2007 16:45:33 -0800, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (Paul Gilmartin) wrote: BTW, and FWIW, I have solved the problem by adding to the code a branch to normal EOF if after opening the input DCB, and before issuing the first GET, the DCBBLKSI is zero. Given the full circumstances of the situation, I see it as a normal condition -- an empty input dataset -- and not an error. But this leaves a pitfall. If a user allocates the data set supplying RECFM, LRECL, and BLKSIZE, but never opens it, you are at the mercy of the previous content of the allocated space, and can ABEND on READ WRONG LENGTH RECORD if the first block read exceeds BLKSIZE, etc. Not if the dataset is allocated on SMS DASD. As noted earlier in this thread, such get an automatic EOF written at allocation time. It's beginning to be rare that production data is not on SMS disks. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 is command reject trying to tell me?
On Sunday 21 January 2007 20:28, Charles Mills wrote: ... The problem is that the BLKSIZE in the DSCB is zero, QSAM picks that up, puts it in a CCW, falls on its face, and diagnoses the situation with a message that it takes a CCW expert to decode -- rather than diagnosing an easily diagnosable situation with a simple explanation. I'm not sure what to make of this. My understanding is that if you OPEN a BSAM or QSAM DCB for INPUT and the F1-DSCB has BLKSIZE=0, you get an S013-34 abend . On a different subject: http://gsf-soft.com/Documents/TRSMAIN-PDSE.shtml -- Gilbert Saint-Flour GSF Software http://gsf-soft.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: Non - ECC, non-parity memory was Re: Risks (Was Re: Decoding the encryption puzzle)
On Sun, 2007-01-21 at 12:59 -0400, Clark Morris wrote: The non-ECC seems to be very reliable on both of the currently used computers at home (1 desktop, 1 laptop). How do you tell the difference between crashes due to memory failures and crashes due to crapware? Some years ago we had a mixture of servers running NetWare -- some of them had ECC memory and some had parity. The ECC-checked servers never burped, but when the parity-checked servers detected a memory fault they raised a NMI and NetWare stopped hard. This happened on the average of once a month in a population of ten servers -- a demonstrable, no fooling memory check. We also had 300 desktop computers that weren't ECC *or* parity checked. I reasoned that since one of every ten machines failed once a month due to memory problems, then 30 times that many unchecked desktop computers were probably failing 30 times as often -- but silently. So once a day, somewhere out in our small network, someone was getting hosed due to a memory failure. Maybe the machine locked up, maybe it just flipped a data bit and made a mess. Nobody knows. I am sure that our help desk took calls for many of these, but there was NO WAY TO TELL what caused the failure. Usually in such cases the tech would blame it on bad karma or cosmic rays. Windows is like that, they'd shrug. Just reboot. Well, Windows *is* like that. But shoddy hardware is a problem too. -- David Andrews A. Duda and Sons, Inc. [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: What is command reject trying to tell me?
Why not just take the matter up with your friendly IBM representative She was downsized in 1996. BTW, it never was an EOF issue. The issue is that QSAM does something stupid and then reports what it did in the most complex way possible. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chris Mason Sent: Monday, January 22, 2007 4:50 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: What is command reject trying to tell me? Charles Now that we've got the EOF issue out of the way, I imagine you are preaching to the converted here. Why not just take the matter up with your friendly IBM representative - who might find his customer satisfaction affected if there's not a logical response to your concern. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 is command reject trying to tell me?
Not what was happening. Take a look at my OP. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Gilbert Saint-Flour Sent: Monday, January 22, 2007 5:30 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: What is command reject trying to tell me? On Sunday 21 January 2007 20:28, Charles Mills wrote: ... The problem is that the BLKSIZE in the DSCB is zero, QSAM picks that up, puts it in a CCW, falls on its face, and diagnoses the situation with a message that it takes a CCW expert to decode -- rather than diagnosing an easily diagnosable situation with a simple explanation. I'm not sure what to make of this. My understanding is that if you OPEN a BSAM or QSAM DCB for INPUT and the F1-DSCB has BLKSIZE=0, you get an S013-34 abend . -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: BLKSIZE=0
99% sure the answer is yes. I know it is possible to open a new dataset and ATTEMPT to read the data already on the tracks. My tests have tended to fail (so to speak) for the reason that I am not trying to read someone else's data, and the tests tend to fail on bad block size (if reading FB) or invalid RCW format (if reading VB). I suspect an attempt reading RECFM=U would succeed. I think IBM's answer to the security issue is an erase feature. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of glen herrmannsfeldt Sent: Monday, January 22, 2007 12:13 AM To: IBM-MAIN@BAMA.UA.EDU Subject: BLKSIZE=0 Charles Mills wrote: 1. It IS on SMS DASD. This is not a theoretical problem -- it happens in real life. The problem is ***not*** with DS1LSTAR or EOF markers. The problem is that the BLKSIZE in the DSCB is zero, QSAM picks that up, puts it in a CCW, falls on its face, and diagnoses the situation with a message that it takes a CCW expert to decode -- rather than diagnosing an easily diagnosable situation with a simple explanation. Is this a (relatively) new problem? As far as I know, OS/360 didn't allow BLKSIZE=0 so this should not happen. At some time later, the ability to specify BLKSIZE=0 was added, along with this problem. Also, is it still possible to open a new data set and read the existing data on the tracks? I know OS/360 would do it, but security requirements have changed since then. (I do remember once having the link editor read some data into SYSLIN that my program never wrote, and then processing it as control cards.) -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 is command reject trying to tell me?
On Monday 22 January 2007 09:12, Charles Mills wrote: Not what was happening. Take a look at my OP. Well, I did, and I saw QSAM, GET, IOS000I, SYNAD, then you said that BLKSIZE=0 in the DSCB. My understanding is that you should get S013-34 at OPEN, and that the IOS000I condition is a bug. Perhaps I am missing something? -- Gilbert Saint-Flour GSF Software 4425 Monserrate St Coral Gables, Florida 33146 USA 1-305-665-9084 http://gsf-soft.com/ -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Of Gilbert Saint-Flour Sent: Monday, January 22, 2007 5:30 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: What is command reject trying to tell me? On Sunday 21 January 2007 20:28, Charles Mills wrote: ... The problem is that the BLKSIZE in the DSCB is zero, QSAM picks that up, puts it in a CCW, falls on its face, and diagnoses the situation with a message that it takes a CCW expert to decode -- rather than diagnosing an easily diagnosable situation with a simple explanation. I'm not sure what to make of this. My understanding is that if you OPEN a BSAM or QSAM DCB for INPUT and the F1-DSCB has BLKSIZE=0, you get an S013-34 abend . -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: LPAR performance questions ?
On Sat, 20 Jan 2007 09:19:50 -0600, Rick Fochtman [EMAIL PROTECTED] wrote: I'm a firm believer in separating TEST workloads from PROD workloads and keeping each in its own LPAR. This way, a run-away CICS transaction in a test CICS can't have anywhere near as much impact on the overall PROD workload. Again, YMMV. Personal preference. Mine is to put test workloads on the same LPAR as production and keep the test LPARs for sysprog work. Let WLM manage the resources on the prod LPAR and give preference to the PROD work. There are advantages and disadvantages to either approach. As you said, YMMV. -- 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: Risks (Was Re: Decoding the encryption puzzle)
On Fri, 19 Jan 2007 11:03:20 -0600, Eric Chevalier wrote: Come on, folks; let's have a little perspective on this issue! Perhaps you can't find laptops with ECC memory because the non-ECC memory is completely reliable for all _practical_ purposes? Am I running a risk of data corruption on my laptop because of some random memory error that goes undetected? Sure. Perhaps it's because it's more expensive and not enough people are willing to pay extra for it. The best clue that I can think of is to look at your mainframe and find out how many memory errors it has corrected this month. If you're on good enough terms with your hardware guy, maybe he'll tell you. It's hard to find. They are not reported to EREP unless there is a _huge_ number of them. My employer's shiny new Z9 processor doesn't have to worry about that particular risk! :-) IIRC, modern processors have beefed up the ECC form the old single bit correction and duoble bit detection to include double bit correction. Do you really think that would have been necessary if modern memories are as reliable as you say? -- 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: RESTART in JCL
On 21 Jan 2007 09:01:28 -0800, [EMAIL PROTECTED] (Chase, John) wrote: During acceptance testing of z/OS 1.7 one of our testers said the following: We used to be able to say RESTART=PSTEP025 or whatever step. I had to change that to RESTART=STEP001.PSTEP025 This is consistent with the JCL Reference manual. The old release on which the above comment is based is z/OS 1.5. Perhaps omitting the STEPNAME was a bug that got fixed? Could you show some sample JCL? -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Non - ECC, non-parity memory was Re: Risks (Was Re: Decoding the encryption puzzle)
On 22 Jan 2007 05:33:23 -0800, [EMAIL PROTECTED] (David Andrews) wrote: How do you tell the difference between crashes due to memory failures and crashes due to crapware? I have a very flaky computer - but repeated long memory tests have not shown the problem to be memory.A workplace could swap memory out and see if the new computer has the problem - I need some evidence before I spend that 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: Decoding the encryption puzzle
On 21 Jan 2007 08:03:52 -0800, [EMAIL PROTECTED] (Shmuel Metz , Seymour J.) wrote: Decades before, people kept printed copies of programs they wrote. The Devil is in the details. Were those programs proprietary? Did those people also take copies of legally protected financial or personnel files? Taking copies of public domain programs is quite different from taking copies of files that your employer is legally required to keep private. Nobody asked whether those programs were proprietary. It never came up. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Decoding the encryption puzzle
On 19 Jan 2007 13:18:32 -0800, [EMAIL PROTECTED] (Ted MacNEIL) wrote: $12? 6/8 GB? (NOTE: That's a 'G' -- GIG!) When I gave that amount, I did not specify a size. The small guys are used for copying data from computer to computer - and they are still larger than mainframe partitions I worked with in Olden Dayze.The big guys are generally used as system backups. And they are cheap enough that people actually buy them and use them. (And they are cheaper, easier, and more reliable than tapes on personal computers). -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Non - ECC, non-parity memory was Re: Risks (Was Re: Decoding the encryption puzzle)
Howard When I ran the memory test it came up with thousands of errors almost instantly. I got my test software from www.docmemory.com Tom Moulder -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Howard Brazee Sent: Monday, January 22, 2007 9:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non - ECC, non-parity memory was Re: Risks (Was Re: Decoding the encryption puzzle) On 22 Jan 2007 05:33:23 -0800, [EMAIL PROTECTED] (David Andrews) wrote: How do you tell the difference between crashes due to memory failures and crashes due to crapware? I have a very flaky computer - but repeated long memory tests have not shown the problem to be memory.A workplace could swap memory out and see if the new computer has the problem - I need some evidence before I spend that 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: Non - ECC, non-parity memory was Re: Risks (Was Re: Decoding the encryption puzzle)
On Mon, 22 Jan 2007 08:06:08 -0700, Howard Brazee wrote: On 22 Jan 2007 05:33:23 -0800, (David Andrews) wrote: How do you tell the difference between crashes due to memory failures and crashes due to crapware? I have a very flaky computer - but repeated long memory tests have not shown the problem to be memory.A workplace could swap memory out and see if the new computer has the problem - I need some evidence before I spend that money. You might have a memory problem, or you might have some other problem. If you have another computer that uses the same kind of memories, you could try swapping them and see what happens. Or if you have two banks of memories, you could try swapping them to see if it bahaves differently It is very difficult to test memory adequately because there are so many different ways that it can fail. One of the most difficult to test for in the case of dynamic RAMs is a bit whose charge drains faster than normal so that it has lost it's value if it isn't refreshed early because of a memory access. The problem witht his kind of error is that your memory test is accessing the memory so fast that the bad bit gets frequently refreshed. Back in the days when I was building my own memory boards using static RAM, I had a series of tests that ran for nearly an hour to run one cycle on a 4K memory board. Double the size of the memory board and it runs four times longer because of the addressing test. -- 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: What is command reject trying to tell me?
In a message dated 1/22/2007 7:30:12 A.M. Central Standard Time, usenet5678 @ YAHOO.COM writes: I'm not sure what to make of this. My understanding is that if you OPEN a BSAM or QSAM DCB for INPUT and the F1-DSCB has BLKSIZE=0, you get an S013-34 abend. ... Gilbert Saint-Flour The OP (_http://bama.ua.edu/cgi-bin/wa?A2=ind0701L=ibm-mainO=DX=75B8E4013E0C7C5F81Y=DASDBILL2%40aol.comP=81257_ (http://bama.ua.edu/cgi-bin/wa?A2=ind0701L=ibm-mainO=DX=75B8E4013E0C7C5F81[EMAIL PROTECTED]P=81257) ) said he had an Assembler subroutine that does GETs with QSAM on a RECFM=FB DCB and that the code had been working until recently. IBM's doc [1] says An error occurred during the processing of an OPEN macro. We don't know the LRECL or OPEN options other than input. Quite a few causes are listed, of which the following seem possible given only the OP's facts: (1) The following combination was specified: QSAM, MACRF=GD or PD, and a RECFM value that is not VS, VBS, DS, or DBS. (2) An OPEN macro instruction was issued for a data set with BLKSIZE and BUFL equal to 0. The system determined that it had to obtain buffers but was unable to do so. (3) The following combination was specified: QSAM, LRECL=0, and a RECFM value that is not V or VB. (4) The following combination was specified: QSAM and BLKSIZE=0. No nonzero BLKSIZE value was available from any source and the system could not determine one. I described in a previous post that the command reject was caused by the Locate Record's transfer length factor's being zero, and then speculated that this was caused by a zero blocksize. With the large number of options available with QSAM DASD I/O, and since the OP did not say he had gotten a S013-34, I think we can conclude that either (1) there are some combinations of operands that include BLKSIZE=0 that will not cause a S013-34 and will allow QSAM to try to do an I/O with an invalid transfer length factor in the Locate Record parameters or (2) there is something else that the OP did not tell us. And regarding being able to read what a track's previous owner left on the track, the answer is of course you can do it. It may be difficult with some access methods, but it is quite easy with EXCP. This assumes that the track has never been erased. Bill Fairchild [1] z/OS MVS System Messages Volume 7 (IEB-IEE), SA22-7637-12; page 191, message IEC141I -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: BLKSIZE=0
In a message dated 1/22/2007 8:16:41 A.M. Central Standard Time, [EMAIL PROTECTED] writes: think IBM's answer to the security issue is an erase feature. There is no other way to enforce the requirement that user A's data cannot be read by user B after user A has released ownership of the tracks and user B subsequently is allowed to allocate the same tracks. Just don't start erasing all tracks in all data sets willy-nilly, or you may have DASD performance problems like you wouldn't believe. Be VERY selective about what you erase. 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: BLKSIZE=0
On Mon, 22 Jan 2007 00:12:34 -0800, glen herrmannsfeldt [EMAIL PROTECTED] wrote: Charles Mills wrote: 1. It IS on SMS DASD. This is not a theoretical problem -- it happens in real life. The problem is ***not*** with DS1LSTAR or EOF markers. The problem is that the BLKSIZE in the DSCB is zero, QSAM picks that up, puts it in a CCW, falls on its face, and diagnoses the situation with a message that it takes a CCW expert to decode -- rather than diagnosing an easily diagnosable situation with a simple explanation. Is this a (relatively) new problem? As far as I know, OS/360 didn't allow BLKSIZE=0 so this should not happen. At some time later, the ability to specify BLKSIZE=0 was added, along with this problem. Depends on what you mean. You could certainly code BLKSIZE=0 on your program. In the shop where I worked in the early '70s, that was the standard. For COBOL programs, it was BLOCK CONTAINS 0 RECORDS. Otherwise, the program had to be changed if the block size changed. Likewise, you could code BLKSIZE=0 in your JCL, though this was less common. What is relatively new is System Determined Blocksize. With SDB, if a new data set is opened and there is no (non-zero) block size specified, the system assigns one. Before SDB, you could get this error if you never specified a blocksize anywhere. -- 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: Decoding the encryption puzzle
$12? 6/8 GB? (NOTE: That's a 'G' -- GIG!) When I gave that amount, I did not specify a size. Then how can we compare? I gave $100.00 for 8GB. You gave $12.00 for WHAT? This makes the response less than useful. . Questions? Concerns? (Screams of Outrage?) -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 is command reject trying to tell me?
1. I did not get any message other than the message in the OP -- specifically, no S013. I'm not intentionally leaving anything out of the story. As I look at the code now, the input DCB OPEN exit provides a maximum size BUFL if it is still zero at the time the exit is drive -- that code was no doubt inserted to work around some other DFSMS obscurity -- so that plug of DCBBUFL may be masking the S013. 2. By working until recently I did not mean to imply that this particular specific situation changed. I meant that the subroutine was tested and generally working in a wide variety of circumstances -- that it was not new code -- and that apparently due to other changes in a product that is undergoing ongoing development, the subroutine was now encountering this situation. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of (IBM Mainframe Discussion List) Sent: Monday, January 22, 2007 7:49 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: What is command reject trying to tell me? In a message dated 1/22/2007 7:30:12 A.M. Central Standard Time, usenet5678 @ YAHOO.COM writes: I'm not sure what to make of this. My understanding is that if you OPEN a BSAM or QSAM DCB for INPUT and the F1-DSCB has BLKSIZE=0, you get an S013-34 abend. ... Gilbert Saint-Flour The OP said he had an Assembler subroutine that does GETs with QSAM on a RECFM=FB DCB and that the code had been working until recently. IBM's doc [1] says An error occurred during the processing of an OPEN macro. We don't know the LRECL or OPEN options other than input. Quite a few causes are listed, of which the following seem possible given only the OP's facts: (1) The following combination was specified: QSAM, MACRF=GD or PD, and a RECFM value that is not VS, VBS, DS, or DBS. (2) An OPEN macro instruction was issued for a data set with BLKSIZE and BUFL equal to 0. The system determined that it had to obtain buffers but was unable to do so. (3) The following combination was specified: QSAM, LRECL=0, and a RECFM value that is not V or VB. (4) The following combination was specified: QSAM and BLKSIZE=0. No nonzero BLKSIZE value was available from any source and the system could not determine one. I described in a previous post that the command reject was caused by the Locate Record's transfer length factor's being zero, and then speculated that this was caused by a zero blocksize. With the large number of options available with QSAM DASD I/O, and since the OP did not say he had gotten a S013-34, I think we can conclude that either (1) there are some combinations of operands that include BLKSIZE=0 that will not cause a S013-34 and will allow QSAM to try to do an I/O with an invalid transfer length factor in the Locate Record parameters or (2) there is something else that the OP did not tell us. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 is command reject trying to tell me?
---snip- 1. It IS on SMS DASD. This is not a theoretical problem -- it happens in real life. The problem is ***not*** with DS1LSTAR or EOF markers. The problem is that the BLKSIZE in the DSCB is zero, QSAM picks that up, puts it in a CCW, falls on its face, and diagnoses the situation with a message that it takes a CCW expert to decode -- rather than diagnosing an easily diagnosable situation with a simple explanation. 2. It's a very specific situation. The dataset is not allocated by a user. It's allocated by a cooperating (semi-cooperative?) automated process -- so Gil's point is correct, but does not apply in my specific situation. --unsnip IIRC, from the beginning of this thread, the LRECL was specified as 0. Why in blazes don't you specify a legal LRECL for a FB dataset, plus DSORG=PS? Then the BLKSIZE won't BE set to zero by SDB and the whole problem goes away? -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: AOPBATCH Continuation character
Dank u wel, Jantje! I know there was a gotcha, but I couldn't remember it... I've got to get back into OE-type stuff - it's been way too long... Later, Ray -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jan MOEYERSONS Sent: Monday January 22 2007 02:09 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: AOPBATCH Continuation character ln: FSUM6245 link to target \ failed: EDC5111I Permission denied. db2jcc_license_cisuz.jar: FSUM7351 not found IIRC, it's the shell, not AOPBATCH, that deals with continuation characters. Try a backslash at the end of the line - although I'm not sure how this will translate with fixed 80 column input - e.g. ln -s $/usr/lpp/db2/db2810/jcc/classes/db2jcc.jar \ db2jcc.jar; It is the back slash alright and it is the shell that is dealing with it. But if your input is fixed length (and it tends to be if it is instream data in a JCL...) then the backslash has to go in exactly the 80th position. Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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
COBOL and Java interoperabitiliy
I know that the current Enterprise COBOL language is documented to be able to invoke Java class methods and vice versa. But I'm curious if anybody out there has actually done anything like this? How difficult is it? Will the Java method be zAAP eligible? Reason: Current management has decided to do a lot of stuff in Java on RedHat Linux. I think it would be interesting to see if we could create some glue on z/OS so that Java on Linux could use JMS to talk to Java on z/OS, which would then use some legacy COBOL I/O routines or business logic. Just some blue sky thinking on my part at this point due to my ignorance of how difficult this would be. Especially given that most COBOL programmers are still a bit reactionary towards doing things differently. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is command reject trying to tell me?
In a message dated 1/22/2007 10:09:16 A.M. Central Standard Time, rfochtman @ YNC.NET writes: IIRC, from the beginning of this thread, the LRECL was specified as 0. Why in blazes don't you specify a legal LRECL for a FB dataset, plus DSORG=PS? IIRC means If I Remember Correctly. YDNRC. That means You Do Not Remember Correctly. From the beginning of this thread, LRECL has never been at issue and BLKSIZE=0 was the issue. If you want to remember correctly, then check the archived posts first. After ascertaining the facts and still being confident of your opinion, then perhaps a phrase like why in blazes would be appropriate. 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: z/OS 1.4 - End of Support
Thank all. --- Chase, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Howard Rifkind I understand that IBM support is being discontinued as of 2/2007. Would anyone know if that would be the beginning of the month or end of the month? Last EOS date I saw published was March 31, 2007. http://www-03.ibm.com/servers/eserver/zseries/zos/support/zos_eos_dates .html -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. http://new.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: What is command reject trying to tell me?
Why in blazes don't you specify a legal LRECL The entire situation is more complex than a listserve note. There are many variables, unknowns, and tradeoffs. One automated process is generating JCL; another process over which I have less control is running under that JCL. I don't specify LRECL, etc., in the JCL because in some cases the automated process does not know in every case what the other process is expecting. This problem is not unsolvable. I am not asking how to solve it. I have solved it. The points of my posts were 1. Initially, could someone who is more up-to-date on channel programs than I please decode the CCW gibberish for me? 2. And then, why the heck can't DFSMS put out a message like illegal blocksize rather than a message like 80AC000404208400FF010F004EA0AC00 FAILING PARAMETER LIST DATA = 868400AC00AC. You guys wonder why the mainframe has fallen from favor and has a reputation for requiring the labor of guys with 40 years of experience to parse its entrails? Look no further than this message. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Monday, January 22, 2007 8:08 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: What is command reject trying to tell me? IIRC, from the beginning of this thread, the LRECL was specified as 0. Why in blazes don't you specify a legal LRECL for a FB dataset, plus DSORG=PS? Then the BLKSIZE won't BE set to zero by SDB and the whole problem goes away? -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: RESTART in JCL
On 1/21/2007 12:01 PM, Chase, John wrote: During acceptance testing of z/OS 1.7 one of our testers said the following: We used to be able to say RESTART=PSTEP025 or whatever step. I had to change that to RESTART=STEP001.PSTEP025 This is consistent with the JCL Reference manual. The old release on which the above comment is based is z/OS 1.5. Perhaps omitting the STEPNAME was a bug that got fixed? I would start by asking the tester to run the same job on your z/OS R5 system to prove that it really works there. I've seen many occasions where someone said we used to be able to do X but they've misremembered exactly how things worked. Since you have both systems available, seeing it work on the old system is a good starting point. Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Mainframe vs. Server (Was Just another example of mainframe costs.)
Steve Better hang onto that card reader and line printer then. Maybe a card punch is needed for the system generation as well. Chris Mason - Original Message - From: Thompson, Steve (SCI TW) [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, 19 January, 2007 2:42 PM Subject: Re: Mainframe vs. Server (Was Just another example of mainframe costs.) ... Let's put this in a mainframe perspective: Imagine that you have decided on a specific type of graphics display and you have only bought those, and you must install a specific driver to use them. So you need to install these during system build, but you can't install a z/OS servrpac unless you can see what you are doing... ... -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: SYSPLEX of LPARS - time problem
Don't forget, this only works if both lpars are on the same CEC. Bob Richards -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Stitt Sent: Monday, January 22, 2007 12:38 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SYSPLEX of LPARS - time problem In your CLOCKxx member, did you specify the SIMETRID parameter? Each member of a sysplex must use the same SIMETRID number. Usually all members of a sysplex use the same CLOCKxx member. On Mon, 22 Jan 2007 11:29:15 -0600, Len Rugen [EMAIL PROTECTED] wrote: I'm trying to add my 2nd lpar to a sysples, but I'm getting message IXC414I CANNOT JOIN SUSPLEX PRODPLEX WHICH IS RUNNING IN MONOPLEX MODE: EXTERNAL TIME REFERENCE IS IN LOCAL MODE The system that is active has PLEXCFG=MULTISYSTEM in IEASYS and at IPL said: IXC418I SYSTEM PROD IS NOW ACTIVE IN SYSPLEX PRODPLEX What am I missing? LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL] -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: SYSPLEX of LPARS - time problem
That's it. And it doesn't look like I can fix the PROD system without an IPL. - Original Message - From: Matthew Stitt [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, January 22, 2007 11:38 AM Subject: Re: SYSPLEX of LPARS - time problem In your CLOCKxx member, did you specify the SIMETRID parameter? Each member of a sysplex must use the same SIMETRID number. Usually all members of a sysplex use the same CLOCKxx member. --- [This E-mail scanned for viruses by Declude Virus] -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: SYSPLEX of LPARS - time problem
Unfortunately, that is the case. But one IPL is all you need to correct this situation. On Mon, 22 Jan 2007 11:56:23 -0600, Len Rugen [EMAIL PROTECTED] wrote: That's it. And it doesn't look like I can fix the PROD system without an IPL. - Original Message - From: Matthew Stitt [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Monday, January 22, 2007 11:38 AM Subject: Re: SYSPLEX of LPARS - time problem In your CLOCKxx member, did you specify the SIMETRID parameter? Each member of a sysplex must use the same SIMETRID number. Usually all members of a sysplex use the same CLOCKxx member. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: RESTART in JCL
I just tested in my 1.2 system and it does not work the way your tester said. I was able to restart only specifying STEPNAME.PROCSTEPNAME even if the proc in question has only one step. The closer thing I remember about proc stepnames is that if you want to pass OVERRIDE DD statements to the first step of the proc you don't need to qualify with the procstepname, but it has nothing to do with restart. On 1/21/2007 12:01 PM, Chase, John wrote: During acceptance testing of z/OS 1.7 one of our testers said the following: We used to be able to say RESTART=PSTEP025 or whatever step. I had to change that to RESTART=STEP001.PSTEP025 This is consistent with the JCL Reference manual. The old release on which the above comment is based is z/OS 1.5. Perhaps omitting the STEPNAME was a bug that got fixed? -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: SYSPLEX of LPARS - time problem
My guess is that systems are pointing to different sets of couple datasets I'm trying to add my 2nd lpar to a sysples, but I'm getting message IXC414I CANNOT JOIN SUSPLEX PRODPLEX WHICH IS RUNNING IN MONOPLEX MODE: EXTERNAL TIME REFERENCE IS IN LOCAL MODE The system that is active has PLEXCFG=MULTISYSTEM in IEASYS and at IPL said: IXC418I SYSTEM PROD IS NOW ACTIVE IN SYSPLEX PRODPLEX What am I missing? -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Non - ECC, non-parity memory was Re: Risks (Was Re: Decoding the encryption puzzle)
David Andrews wrote: [...] Some years ago we had a mixture of servers running NetWare -- some of them had ECC memory and some had parity. The ECC-checked servers never burped, but when the parity-checked servers detected a memory fault they raised a NMI and NetWare stopped hard. This happened on the average of once a month in a population of ten servers -- a demonstrable, no fooling memory check. Once a month? What hardware did you use??? I administered dozens of NetWare servers (and others as well), usually running on generic PC from Taiwan R.O.C. (usually assembled by me). I experienced several disk failures, sometimes power supplies and others (in fact I can't remember failing RAM). *Never used ECC memory*. However average uptime was approx. 3 months and restarts were done by routine, (it was suggested), not because it was necessary. We also had 300 desktop computers that weren't ECC *or* parity checked. I reasoned that since one of every ten machines failed once a month due to memory problems, then 30 times that many unchecked desktop computers were probably failing 30 times as often -- but silently. I also administered hundreds of end-user PC's. Part of them (the older part) were on parity RAM, the newer ones were without parity. THe system was DOS, DOS+Win 3.1, Win95. There were failures, both hw and sw, but the frequency was *significantly* lower. BTW: I used 9672 machine. zero downtime, fully redundant. During *whole period of exploitation* we had power supply problem. It was blank new machine, under IBM service. They tried almost everything, replaced power supplies, internal batteries, etc. No effect. Although the CPC was working fine, the HMC got Power problem message on regular basis. We used it for few years, upgraded it during exploitation period, but the power problem was never fixed. Crappy hardware ? -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: LPAR's and CPU's
Thanks Adam, good book. Skimmed the chapters on CPU management and dispatching processors to lpars. Got it bookmarked, and will spend more time reading soon. Thanks again. --Dave Day - Original Message - From: Gerhard Adam [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Sunday, January 21, 2007 8:01 PM Subject: Re: LPAR's and CPU's All of the recent posts regarding LPAR's and their CPU utilization prompts a couple of questions on my part. 1)Does anyone know the mechanism used to distribute CPU's to LPARS while they are running? Another way of stating this question is what happens to the executing TCB or SRB on a given processor in LPAR A when the code in charge of distributing CPU resources decides LPAR A has consumed enough, and LPAR B should now get the processor? I would assume it forces some interrupt on the processor, probably a CPU timer, but am curios if this is correct? 2)Is there any accounting for this loss of processor availability within MVS? The MVS dipatcher running in an LPAR that had n+ processors to use, and now has n, how does it get notified it has one or more less processors to use, and then at a later time, one or more additional to dispatch on? I've searched IBM's web site for doc and can't find anything. If there's a redbook out there that talks about this, I'd appreciate a link to it. 1. Nothing in particular happens to the TCB/SRB since z/OS doesn't know about it. The loss of actual computing power is conveyed by a lower SRM constant as the number of engines increases. 2. When a reduction or increase in processors is relayed to z/OS by configuring processors on or offline. (Either by operator action or IRD) 3. If an operator configures a processor on or offline, the SRM constant is recalculated. This is NOT done when the processors are brought on or offline by IRD. 4. Good documentation on this is in the Redbook Intelligent Resource Director. Hope this helps Adam -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Non - ECC, non-parity memory was Re: Risks (Was Re: Decoding the encryption puzzle)
I like http://www.memtest86.com/ FREE, GPL, bootable ISO you can download. Memtest86 - A Stand-alone Memory Diagnostic Memtest86 is thorough, stand alone memory test for x86 architecture computers. BIOS based memory tests are a quick, cursory check and often miss many of the failures that are detected by Memtest86. Memtest86 is released under the terms of the Gnu Public License (GPL). Other than the provisions of the GNU public licence (GPL) there are no restrictions for use, private or commercial. Explicit permission for inclusion of Memtest86 in software compilations and publications is hereby granted. Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Moulder Sent: Monday, January 22, 2007 10:18 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non - ECC, non-parity memory was Re: Risks (Was Re: Decoding the encryption puzzle) Howard When I ran the memory test it came up with thousands of errors almost instantly. I got my test software from www.docmemory.com Tom Moulder This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Deleting HSM Backups questions -- Part 2
A month ago I said, Hundreds of HSM [backup] tapes that CA-1 says were created 1999, 2000, 2001. And I soon realized that those were the years (1999 thru 2001) when we were running OS390 v2.5, so maybe it was either a Y2K Problem or an OS390 v2.5 situation. That realization helped me to understand the potential significance of Richard Marchant's posting to IBM- MAIN on 24 July of 2002 (Re: FIXCDS -- yes, but WHAT?) in which there was the statement HSM CONNECTED TAPE SET PROBLEM - HOW TO FIX (OS390 2.10 now fixed!). That caused me to examine the situation further. Richard said, HSM is currently (Nov99) having a problem connecting tape sets and periodically the first tape in a set is disconnected and recycled. This leaves the rest of the set without a first tape and cannot be recycled. Our total dasd farm consists of 89 volsers; all are 3390-3. My LIST TTOC reports showed 16 tape volsers for ML2, and about the same quantity for SPILL, but more than 330 volsers for DAILY backups. That suggests that a whole lot of tapes did not recycle in those years of v2.5. Almost all of those old DAILY tapes did show a volser in the PREV VOL column of the TTOC report, but they all show *NONE* in the SUCC VOL column. So if I tried to restore a spanned dataset from one of these backups (a dataset that continues on another tape volume) HSM would not know where to find the next part of the dataset being restored. Per Richard's suggestion, I performed a FIXCDS for each of those volsers to blank the PREV VOL (I will still be unable to restore a spanned dataset), then did some EXPIREBV's and RECYCLEs, and now have 16 ML2 tapes, 18 Spill tapes, and 2 Daily tapes. That's right, 2 -- two -- T-W-O Backup tapes instead of the 332 Daily Backups that were reported before. (And it seems to have gotten rid of many or most of our 7,000+days-old backups, which I had mentioned last month.) I don't know whether any release of z/OS actually performed a correction of this nature for *your* shop (I suspect not), so there is a possibility that you too have lots of 3590's tied up in really old backups, and you might not be aware of it. If you or your colleagues haven't already done so, you might try an HSM LIST BACKUPVOLUME and check the Last Backup Date column for reasonableness. [Use command HSEND FIXCDS t 01-volser- PATCH(X'18' X'404040404040') where the Hex value alters the PREV VOL attribute.] There might be more HSM stuff that I could try to do, but I have declared victory, and have went home. Larry M. Burch City of Albuquerque Albuquerque NM USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
PSI sues IBM in mainframe emulator spat (Not Phoenix !)
New suit from PSI I hadn't seen anyone mention. Looks like PSI are counter suing and citing restraint of trade and antitrust violations. This is in response to IBM suing PSI last month. Details at http://www.theregister.co.uk/2007/01/22/platform_solutions_sues_ibm/ Jerry Whitteridge Safeway Inc 925 951 4184 MMS safeway.com made the following annotations. -- Warning: All e-mail sent to this address will be received by the Safeway corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain information proprietary to Safeway and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
It's not too late to SHARE
It's not too late to set a course for SHARE February 12 - 16 in Tampa. Besides all the usual goodies we offer, this conference coincides with the GA of STP (Server Time Protocol), which will finally untether us from the short leash of the sysplex timer. Just as parallel sysplex offered virtual 24x7x365 (*) availability to the end user for systems collocated in the glass house, STP extends the sysplex bounds far beyond the constraints of the conventional campus environment. There's still time to register and reserve a hotel room within walking distance of the session venue. If you haven't already made plans to attend, the opportunity beckons. (*) I love this numerical hyperbole. If you do the math, it works out to seven years, or one dog year in common parlance. I guess end user availability is truly man's best friend. . . JO.Skip Robinson Southern California Edison Company SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [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: PSI sues IBM in mainframe emulator spat (Not Phoenix !)
On Mon, 22 Jan 2007 16:26:44 -0700, Jerry Whitteridge wrote: Details at http://www.theregister.co.uk/2007/01/22/platform_solutions_sues_ibm/ Interesting phrase there: ... the mainframe systems architecture developed by Amdahl ... Apparently attributable to Register, not PSI, and true in a sense, but otherwise misleading. -- 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: Shadow 6.1.3.6289
Hi, Ok, I just figured out that Shadow use our Production CICS as a Natural Batch Server. Initially, I thought Shadow uses CICS for the TP component but that is not true. They use CICS for the Natural RPC calls. Like Entire Broker would be using 'EntireX Servers'. Only problem is, they use the 'CICS SVC/EXCI' interface and Entire Broker uses the Adabas SVC for their spawning of the Natural program. Entire Servers can be predefined but Shadow passes all that to CICS and the Natural/Cics threads that are unlimited in our Production CICS. Not sure yet how SHadow gets around the overhead of the Natural Nucleus Initialization at the start of each Natural Transaction in CICS. Note: Amazing stuff !! Anton Schulz, Mark wrote: We are running Version 6.1.1.4396 in our Test/Development area. It should go into production this first quarter. The differences between this release and 6.1.3 are not that significant (at least in how the release notes impact us) - so we may go with 6.1.3 before the move to production. Mark Schulz -Original Message- From: Software AG Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Anton Britz Sent: Friday, January 19, 2007 9:25 AM To: [EMAIL PROTECTED] Subject: Shadow 6.1.3.6289 Hi, Is there anybody out there that is running this version of Shadow yet ? VErsion 6.1.3.6289.. Anybody, it does not matter how big you are or who you voted for in the last election. Anton -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Java and COBOL
McKown, John wrote: I know that the current Enterprise COBOL language is documented to be able to invoke Java class methods and vice versa. But I'm curious if anybody out there has actually done anything like this? How difficult is it? Will the Java method be zAAP eligible? Some time ago I heard that one of the first non-Java compilers to generate JVM code was a COBOL compiler. I don't know any more about it, but that is where I would look first. -- glen -- For IBM-MAIN subscribe / signoff / archive access instructions, 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 and Java interoperabitiliy
One key issue is Identity Flow - once user authenticated on Linux side - how can Identity pass across as already verified to the z/OS side in order to be used in authorizations? Async media like MQ/JMS may not pass Identity transparently - better a synchronous solution. CTG, WebSeal , Federated Identity) are some products in the space of Identity Flow. Closely related - there is a redbook on using RACF via an LDAP client on z/Linux - if need to extend RACF to Linux side. Shmuel Koller From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Monday, January 22, 2007 6:31 PM To: IBM-MAIN@BAMA.UA.EDU Subject: COBOL and Java interoperabitiliy I know that the current Enterprise COBOL language is documented to be able to invoke Java class methods and vice versa. But I'm curious if anybody out there has actually done anything like this? How difficult is it? Will the Java method be zAAP eligible? Reason: Current management has decided to do a lot of stuff in Java on RedHat Linux. I think it would be interesting to see if we could create some glue on z/OS so that Java on Linux could use JMS to talk to Java on z/OS, which would then use some legacy COBOL I/O routines or business logic. Just some blue sky thinking on my part at this point due to my ignorance of how difficult this would be. Especially given that most COBOL programmers are still a bit reactionary towards doing things differently. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
