Re: Help with deleting datasets which are not cataloged or don't exist.
To me, it sounds like this dataset is orphaned in the wrong usercat. You need to temporary delete the alias to the correct usercat; delete the cluster with the catalog parameter (or define the alias to the wrong usercat before the delete); finally define the alias back to the correct usercat. Hope that helps. -- For IBM-MAIN subscribe / signoff / archive access instructions, send 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 deleting datasets which are not cataloged or don't exist.
I'm sure we can help you but I suspect a phone call will be needed. Why don't you email me directly and I can give you my direct phone number. I promise not to push any vendor tool on you! I'm sure we can get to the bottom of this by using LISTCAT, perhaps some VTOC lists, some prints of your VVDSs, etc. [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind Sent: Tuesday, October 07, 2008 4:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Help with deleting datasets which are not cataloged or don't exist. Hello all, I'm trying to delete the following datasets: PDB.SYSPROG.TMON.LMCICS.V22.VTCECNTL *VSAM* PDB.SYSPROG.TMON.LMCICS.V22.VTCECNTL.DATA OPSPR2 PDB.SYSPROG.TMON.LMCICS.V22.VTCECNTL.INDEX OPSPR2 For the first one a 'D' states that it isn't cataloged. For the other two a 'D' states that the datasets don't exist. I've tries a delete NVR and a normal delete. Nothing works. Can anyone make some suggestions as how to get these out of the system. An ISPF 3.4 is showing these up. Thanks. _ LEGAL NOTICE Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately, then delete this message and empty from your trash. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Help with deleting datasets which are not cataloged or don't exist.
If you use the CATALOG(xxx) parameter, you don't need to delete or redefine the alias. Bruce Richardson wrote: To me, it sounds like this dataset is orphaned in the wrong usercat. You need to temporary delete the alias to the correct usercat; delete the cluster with the catalog parameter (or define the alias to the wrong usercat before the delete); finally define the alias back to the correct usercat. Hope that helps. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: OSA ICC Consoles
We really appreciate you taking the time to enlighten us. Could you comment on the observation that ICC consoles can be expected to be offline in various start up scenarios? For example, z/os 1.7 POR, z/os 1.9 POR, 'Rolling IPL' for those two? Thanks!! -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of W. Kevin Kelley Sent: Wednesday, October 08, 2008 5:38 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: OSA ICC Consoles Yes, I have been following this discussion... First of all, Consoles does not keep any console information in the couple data sets. Secondly, the console attribute retention behavior has changed as a result of the Console Restructure. Prior to the Console Restructure, when a console was activated for the first time, we fetched the attributes of the console either from PARMLIB or from OPERPARM depending on the type of console. If changes were made to any of the attributes of the console -- either while it was active or not -- those changes were retained and used whenever the console was reactivated -- as long as a simultaneously sysplex-wide IPL did not occur, in which case we fetched the attributes again from PARMLIB or OPERPARM. The reason this behavior occurred was because every system in the sysplex had a copy of all of the attributes for every console defined in the sysplex. Whenever an attribute was changed (by command), the change was propagated to every system in the sysplex. As long as there was one surviving system, it was able to pass the altered console attributes to any new system joining the sysplex. The only way to get Consoles to forget the altered console attributes was to make sure that -all- of the systems in the sysplex were dead before re-IPLing. Many customers were completely unaware of this behavior. One of the problems we were attempting to solve with the Console Restructure was the amount of console attribute information that we were constantly passing from one system to another (under serialization) to keep everybody in-synch. We had situations where a system joining the sysplex would request a copy of the console information and before it could be completely received, the information had changed and had to be fetched again. We had some cases where the system never got out of that loop and the update storm then propagated to other systems in the sysplex, hanging the entire sysplex. So as part of the Console Restructure, we made a concious decision to not have every system in the sysplex have a complete copy of all of the console information. (We had to back off of that somewhat due to some problems, but that was the intent). In z/OS R10, there is a new operations mode called SHARED mode that you can migrate to. In that mode, we only keep track of the attributes of active consoles. Once the console is deactivated, we forget its attributes, and when it is reactivated we refetch its attributes from PARMLIB or OPERPARM. All of the systems in the sysplex are still aware of all of the attributes of all of the consoles, but only the active ones. Also, we use a lazy update technique to propagate attribute changes from one system to another, but this is done using timestamp based serialization rather than the sysplex-wide ENQs that we used to use. In the past, the attributes had to be in-synch all around the sysplex because systems were making message routing decisions based on those attributes. We don't do that to the extent that we used to, so the lazy update is adequate. The primary reason we continue to propagate the attributes to all of the systems in the sysplex is so that DISPLAY CONSOLES will work. W. Kevin Kelley IBM POK Lab -- z/OS Core Technical Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PDS LOCk
Be sure you understand the installation's security rules. I can't believe that there wouldn't be naming conventions in place that would allow datasets to be named so as to get appropriate access protection even for test/training/non-production datasets. If you are somehow dealing with a special test or development environment where everyone has access to everything, that sounds like a disaster waiting to happen. RACF by default gives a user ALTER access (CREATE/UPDATE/READ/DELETE) to any dataset with a high-level-qualifier (HLQ) of his own userid. These datasets should be private to that user by default, unless the installation has deliberately granted access to many others by explicit PERMITS or by giving an exceptional number of users OPERATIONS authority to access all datasets not explicitly denied. Either of those actions seems highly unreasonable, but that doesn't mean some installations might not have done it. Normally data that should be considered private to one user would have his userid as HLQ. Datasets that are to be shared by multiple users would normally be given a HLQ that is not a userid, and explicit access would be granted to specific RACF groups or users as required. There is no reason why additional groups cannot be established (by a Security Admin) if new access patterns arise. RACF protects at the dataset level, not at the PDS member level. If you have members with different security requirements, they will have to be kept in distinct PDS libraries with different access permissions. If your real goal is to prevent unauthorized updates to a specific database, the UPDATE authority to that database should be restricted, whether other users can get to your JCL or not. In z/OS, protection by ignorance (of constructing functional JCL) is not an acceptable practice. J C Ewing Ram Balaji wrote: Hi Anton/john, John your assumptions are correct, 1)Iam just a programmer. 2)Sensitive data (I should have clearly explained this point). My sensitive datas are training datasets which I have created dealing with training database. Many times I see?people trying to explore my dataset and run them. I dont mind ppl using my dataset but these program point?Training DB, Iam bit worried about this. I cant ask SAF to Protect since its my training dataset. Moreover keeping it in a notepad file is good option. But cant we make it bit easier(within Mainframes 3) Database should be visible to me alone. 4) Iam using Z/OS. Hey JOHN Thanks a lot for all your valuable suggestion. I tried using TSO PROTECT , this is no more a working command. Any other solution? Hope I made it clear. Sorry for delayed response. Regards, Ram Balaji.S. (Dying Hard to explore MainFrames) -Original Message- From: John McKown [EMAIL PROTECTED] To: IBM-MAIN@BAMA.UA.EDU Sent: Tue, 7 Oct 2008 6:08 pm Subject: Re: PDS LOCk On Tue, 7 Oct 2008, Anton Britz wrote: Hi Ram, Do not get confused with all these technical discussions that you received but lets start at the very beginning : a) Are you a User , a Systems programmer or just a programmer For some reason, I just ASSuMEd that he was likely a programmer. b) If you say sensitive data .. what do you mean by that Good point. If it is personal data, then I'd strongly suggest that it does not belong on a company machine. c) Who should be able to see this data ? ex. Only you, Your Department Again, on a company machine, only you should not be an option, IMO. Reminds me of some foolish print operators at a place that I used to work. The printer was a Xerox 8700 laser. The operators placed sensitive personal information in a file on it, thinking that nobody else would ever see it. Management was not amused when the machine was audited by a Xerox person. They were quickly shown the error of their ways, and the door. Any wonder that I'm paranoid? grin. d) What operating system are you using Do PDS'es exist on anything other than z/OS? I know that z/VSE has something similar, but the name is different. At least according to my fading memory. Anton -- Joel C. Ewing, Fort Smith, AR[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: REXX EXEC
Shmuel Metz , Seymour J. wrote: In [EMAIL PROTECTED], on 09/24/2008 at 11:22 PM, Ted MacNEIL [EMAIL PROTECTED] said: More to the point, century year that is not a mod 400 year is not a leap year. Not quite, but the adjustment won't be in my lifetime. Well, actually, quite. The 4/100/400 year rule started by Pope Gregory is the only rule adopted by any country using the Gregorian calendar, so that is the current definition of leap year. That at the current movement of the Earth an additional correction may be needed by around 3200 can be demonstrated, but no attempt to revise existing standards has been taken (and probably won't be until 3195 :) ). Heck, by then we may have either managed to wipe out civilization, altered the speed of the Earth, or changed to some other system of measuring time, so no hurry. -- Joel C. Ewing, Fort Smith, AR[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: Finding Variables in C++ Dump
2008/10/9 Bernd Oppolzer [EMAIL PROTECTED]: A variable which is listed in the storage offset listing as 0(r13) actually never is held in storage, but it resides in a register all the time. 0(r13) simply means that no storage is allocated for this variable (this is not very nice, I asked the compiler people several times to fix this. Some compiler versions simply give no offset at all in these cases, only a line with the variable name and a comma instead of an offset.) A variable without allocated storage must be a simple local variable which fits into a register (that is, a pointer, long, int, double etc.). This is never the case for parameters (they are addressed with r1 and never transferred by registers, always storage), or parts of a struct, or variables which need to be addressed by pointer. And, of course, not for char arrays, decimal values and so on, because they must reside in storage. With FASTLINK and XPLINK, some arguments are normally passed directly in GPRs 1-3, and/or FPRs 0-6, and R1 does not point to the argument list. The only way to determine the actual register number is to look at the assembly code around the error place. If you have something like x = 0; *** la r6,0 you know, for example, that r6 is used to hold the value of x. Keep in mind that this is not necessarily a fixed assignment, i.e. R6 may hold some other variable at some other point in the code, and some other register may hold the value of x. If you are in a position to reproduce the problem easily, it can make debugging at this low level easier if you compile with all optimizations turned off. And sometimes that even makes the problem go away... :-( 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: Finding Variables in C++ Dump
Thanks for the responses, guys. Looking closer at the pseudo assembly listing revealed that the compiler was stuffing this variable at +FC into the DSA into a variable that it decided to call #SPILL2. Since the compiler leaves no comments behind, at least the line numbers can be used to see which machine instructions are for which line of code. From the pseudo assembly listing: 000248 | * for (l_iRetColLoc = 0; [while condition]; l+iRetColLoc++) Soon after this in the listing: 000248 | STr1,#SPILL2(,r13,252) (R1 has a zero in it from some other variable at this point) 000248 |@78L527 DS0H (label for branching back to top of the loop) And farther down in code: 000248 | L r0,#SPILL2(,r13,252) 000248 | AHI r0,H'1' 000248 | L r14,[EMAIL PROTECTED](r7,r2,0) 000248 | LTR r14,r14 000248 | STr0,#SPILL2(,r13,252) 000248 | BNE @78L527 (only other area where label #78L527 is referenced) Small comment on this... I wish that the mnemonic testing the condition code here was BNZ rather than BNE since the previous instruction to set the condition code was LTR and the operands will always be equal... Oh well, I'll live. Adam Johanson IMS Systems Programming USAA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
V Ranieri Jr is out of the office.
I will be out of the office starting 04/10/2008 and will not return until 12/10/2008. Estarei ausente com acesso restrito a e-mail. Retornarei em 12/Outubro. Para assuntos urgentes, favor contatar minha gerente Cintia Lima no ramal 6919. Obrigado. I am out of office with restrict access to e-mail. I will be back on October 12. For urgent matter, please call my manager Cintia Lima at extension 6919. 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
LE module CELHV002?
Does anybody know that this really does? I'm running a C++ program in batch. Basically, it is a program which reads information from a network connection and is writing it out to a tape dataset. I don't have the source. For those interested, it is the todsn program in the Co:Z package from Dovetailed Technologies (which I really like!). The job running this program is taking about 20% of a z9BC-V02, or about 40% of a single engine. For all I know, that is normal. But I would have thought the program would be more I/O bound than that. More curious than anything else. -- 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
IOCDS Question
Just finished a roll out of a new IODF/IOCDS across all five of my active LPAR's. All the displays except one are as expected. The one odd display is on the HMC Activation Profile for the POR profile. The list of IOCDS's look good, but the 'current active' does not agree with any of the other displays. It looks to be two steps back. Clues, anyone? z/890 under z/os 1.7 No POR's since the box was installed. All changes have been dynamic. 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: IOCDS Question
I wouldn't expect them to match if dynamic activity has take place since the last POR. I believe the IOCDS is write protected for the life of the POR. What happened when you built the new IOCDS (i.e., wrote it out to the SE)? Regards, Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Thursday, October 09, 2008 2:48 PM To: IBM-MAIN@BAMA.UA.EDU Subject: IOCDS Question Just finished a roll out of a new IODF/IOCDS across all five of my active LPAR's. All the displays except one are as expected. The one odd display is on the HMC Activation Profile for the POR profile. The list of IOCDS's look good, but the 'current active' does not agree with any of the other displays. It looks to be two steps back. Clues, anyone? z/890 under z/os 1.7 No POR's since the box was installed. All changes have been dynamic. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IOCDS Question
On Thu, 9 Oct 2008 15:41:44 -0700, Neubert, Kevin wrote: I wouldn't expect them to match if dynamic activity has take place since the last POR. I believe the IOCDS is write protected for the life of the POR. What happened when you built the new IOCDS (i.e., wrote it out to the SE)? I don't have a clue to help Hal, but I know you can update an active IOCDS via HCD. I did that a few weeks ago and generated an out-of-sync condition for myself. This last POR cleared it up, but it was interesting that I couldn't dynamically activate the IOCDS. I probably could have backed up a version and then re-activated, but I would have ended up blowing away some active devices (consoles) and didn't want to deal with that. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IOCDS Question
Return code zero - nothing unexpected. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Neubert, Kevin Sent: Thursday, October 09, 2008 5:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: IOCDS Question I wouldn't expect them to match if dynamic activity has take place since the last POR. I believe the IOCDS is write protected for the life of the POR. What happened when you built the new IOCDS (i.e., wrote it out to the SE)? Regards, Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Thursday, October 09, 2008 2:48 PM To: IBM-MAIN@BAMA.UA.EDU Subject: IOCDS Question Just finished a roll out of a new IODF/IOCDS across all five of my active LPAR's. All the displays except one are as expected. The one odd display is on the HMC Activation Profile for the POR profile. The list of IOCDS's look good, but the 'current active' does not agree with any of the other displays. It looks to be two steps back. Clues, anyone? z/890 under z/os 1.7 No POR's since the box was installed. All changes have been dynamic. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LE module CELHV002?
On Thu, 9 Oct 2008 15:41:36 -0500, John McKown wrote: Does anybody know that this really does? I'm running a C++ program in batch. Basically, it is a program which reads information from a network connection and is writing it out to a tape dataset. I don't have the source. For those interested, it is the todsn program in the Co:Z package from Dovetailed Technologies (which I really like!). The job running this program is taking about 20% of a z9BC-V02, or about 40% of a single engine. For all I know, that is normal. But I would have thought the program would be more I/O bound than that. More curious than anything else. My bet is Java with that kind of resource utilization. Do you see a task associated with it in PS ??? I'm trying to track a couple of resource hogs right now too, but I'm having trouble relating the batch JOB with a background process. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
is out of the office.
I will be out of the office starting 10/09/2008 and will not return until 10/14/2008. I will be out of the office on Friday, October 10th and Monday, October 13th. I will return on Tuesday, October 14th. Thanks. ** The information contained in this communication is confidential, private, proprietary, or otherwise privileged and is intended only for the use of the addressee. Unauthorized use, disclosure, distribution or copying is strictly prohibited and may be unlawful. If you have received this communication in error, please notify the sender immediately at (312)653-6000 in Illinois; (800)835-8699 in New Mexico; (918)560-3500 in Oklahoma; or (972)766-6900 in Texas. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Previous release of redbook
I'm looking for previous relase of System z Connectivity Handbook SG24-5444. Now it's SG24-5444-08 and does not include any information regarding z/900. Redbook web page does show me only the latest issue. How can I find old release of the book? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2008 r. kapitał zakładowy BRE Banku SA wynosi 118.642.672 złote i został w całości wpłacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send 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 deleting datasets which are not cataloged or don't exist.
Hi I replied yesterday on the Google group forum for IBMMAIN but saw no posting when reading the Listserv postings today What I have to say is if the VSAM is definitely uncataloged then the following will work ) Run an IEHLIST LISTVTOC of the volume on which the VSAm DS resides 2) Check that the entry for the DSname is in the VTOC and that offset X'52' in the Format-1 DSCB is equal to '14' 3) Run AMAZPZAP to zap the 14 to 10 for the name entry 4) Run IEHPROGM to SCRATCH the Dataset. IEHPROGM now thinks it is a Sequential DS Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Previous release of redbook
Radoslaw, only latest redbooks are available (or draft, if it is more fresh). The oldest I have is -05, I will send it to you privately. Marian Gasparovic IBM Slovakia 2008/10/9 R.S. [EMAIL PROTECTED]: I'm looking for previous relase of System z Connectivity Handbook SG24-5444. Now it's SG24-5444-08 and does not include any information regarding z/900. Redbook web page does show me only the latest issue. How can I find old release of the book? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2008 r. kapitał zakładowy BRE Banku SA wynosi 118.642.672 złote i został w całości wpłacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Finding Variables in C++ Dump
A variable which is listed in the storage offset listing as 0(r13)
actually never is held in storage, but it resides in a register all the time.
0(r13) simply means that no storage is allocated for this variable (this
is not very nice, I asked the compiler people several times to fix this.
Some compiler versions simply give no offset at all in these cases, only
a line with the variable name and a comma instead of an offset.)
A variable without allocated storage must be a simple local variable
which fits into a register (that is, a pointer, long, int, double etc.).
This is never the case for parameters (they are addressed with r1 and
never transferred by registers, always storage), or parts of a struct,
or variables which need to be addressed by pointer. And, of course,
not for char arrays, decimal values and so on, because they must reside
in storage.
The only way to determine the actual register number is to look at the
assembly code around the error place. If you have something like
x = 0;
*** la r6,0
you know, for example, that r6 is used to hold the value of x.
Kind regards
Bernd
Am Mittwoch, 8. Oktober 2008 23:45 schrieb Adam Johanson:
I am trying to locate some variables in a C++ dump. The dump is an SVC dump
of an IMS MPR for a completion code U0240. The variables are defined inside
the function for the class.
For example:
ClassA::functionB (parm1, parm2, parm3)
{
// some variables
int l_iRetColLoc;
// some more variables
...
}
When I look at the storage offset listing for l_iRetColLoc, it says that
its location is at 0(r13). Looks like this means the offset into the
class that it's part of. But since it's not part of a class, it's at
offset 0 into itself.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Finding Variables in C++ Dump
BTW: ad if you are in Europe and you want me to hold a class on such things in German or English, please contact me offline. /ad Kind regards Bernd Am Donnerstag, 9. Oktober 2008 09:47 schrieb Bernd Oppolzer: A variable which is listed in the storage offset listing as 0(r13) actually never is held in storage, but it resides in a register all the time. 0(r13) simply means that no storage is allocated for this variable (this is not very nice, I asked the compiler people several times to fix this. Some compiler versions simply give no offset at all in these cases, only a line with the variable name and a comma instead of an offset.) A variable without allocated storage must be a simple local variable which fits into a register (that is, a pointer, long, int, double etc.). This is never the case for parameters (they are addressed with r1 and never transferred by registers, always storage), or parts of a struct, or variables which need to be addressed by pointer. And, of course, not for char arrays, decimal values and so on, because they must reside in storage. The only way to determine the actual register number is to look at the assembly code around the error place. If you have something like x = 0; *** la r6,0 you know, for example, that r6 is used to hold the value of x. Kind regards Bernd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Previous release of redbook
I sent to personal email a copy of -02 and 04 of book. Why IBM remove them from web site Some good information can be missed from old releases. Carlos R.S. escreveu: I'm looking for previous relase of System z Connectivity Handbook SG24-5444. Now it's SG24-5444-08 and does not include any information regarding z/900. Redbook web page does show me only the latest issue. How can I find old release of the book? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Emulators
Ram Balaji wrote: Is there any free?Mainframe(JCL,CICS) simulators available for desktop PC? The z390 Portable Mainframe Assembler and Emulator open source J2SE java based tool includes TN3270 client server emulation over TCP/IP sockets and there is support for EXEC CICS assembler applications including SEND, RECEIVE, BMS mapping etc. which can be run on Windows or Linux with multiple clients on same or different processors on the same TCP/IP network. There are demo and regression tests plus an SOA type client server application generator which includes support for assembler and COBOL applications via EZSOKET interface. Visit www.z390.org for download in Windows InstallShield or Linux file image format plus documentation. Come to the next SHARE conference in Austin TX for session on z390 Tuesday, March 3, 2009 8:00 with update on what's new including support for open source Structured Programming Extensions (SPE's) for conditional macro code and Structured Programming Macros (SPM's) all written using SPE so there are no explicit AIF or AGO macro labels! There will be live demo of new tool which has over 100 new structured macros all using SPE's and SPM's to provide a very powerful and easily extendable tool. Come see what it is? Don Higgins [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: Emulators
Don Higgins wrote: Come to the next SHARE conference in Austin TX for session on z390 Tuesday, March 3, 2009 8:00 with update on what's new including support for open source Structured Programming Extensions (SPE's) for conditional macro code and Structured Programming Macros (SPM's) all written using SPE so there are no explicit AIF or AGO macro labels! There will be live demo of new tool which has over 100 new structured macros all using SPE's and SPM's to provide a very powerful and easily extendable tool. Come see what it is? I will! -- 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
OT: Unisys mainframes on Xeon
Although not about IBM mainframes, I think this article is interesting. It does touch, peripherally on why mainframes as a class continue to exist. http://www.theregister.co.uk/2008/10/08/unisys_clearpath_kickers/ -- 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: PDS LOCk
Ram, I was also in the Outsourcing business for 10 years so here comes my opinion : a) You have to speak/find the Software support staff for the Computer that you are working on b) Tell them what you want to do and then ask them, what do they think you should do. They would help you, if only they know what and where you.. Note: There has to be a Software programmer that set the Machine/Operating system up. You just have to find him/her and it would be a better way to approach this problem. Anton On Wed, 8 Oct 2008 14:37:16 -0400, Ram Balaji [EMAIL PROTECTED] wrote: Hi Anton/john, John your assumptions are correct, 1)Iam just a programmer. 2)Sensitive data (I should have clearly explained this point). My sensitive datas are training datasets which I have created dealing with training database. Many times I see?people trying to explore my dataset and run them. I dont mind ppl using my dataset but these program point?Training DB, Iam bit worried about this. I cant ask SAF to Protect since its my training dataset. Moreover keeping it in a notepad file is good option. But cant we make it bit easier(within Mainframes). 3) Database should be visible to me alone. 4) Iam using Z/OS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send 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 deleting datasets which are not cataloged or don't exist.
First you need to check all the components. The LISTCAT is listing the BCS. You should list the VVDS of the volume where the DATA and INDEX components are located. Check if the entries are there and if they point to the right catalog. Also, using 3.4 and specifying the VOLSER, see if the datasets are there (if they have DSCB-1). The commands to be used depend on what you find. This is a sample job to list the VVDS: //DEFFIL01 EXEC PGM=IDCAMS,REGION=2M //SYSPRINT DD SYSOUT=Q //DDVVDS DD DSN=SYS1.VVDS.VSMSV01,DISP=SHR,AMP=AMORG,UNIT=SYSDA, //VOL=SER=SMSV01 //SYSIN DD * PRINT INFILE(DDVVDS) SKIP(000) /* Where you must replace all SMSV01 with your volser. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
