Re: Of interest to the Independent Contractors on the list
From: Graeme Gibson gra...@ase.com.au To: IBM-MAIN@bama.ua.edu Sent: Wed, May 19, 2010 6:13:37 AM Subject: Re: Of interest to the Independent Contractors on the list How many of those Prophets of Doom knew what they were talking about but it worked for most executives. The doom would have been real enough if the prophets had been ignored. -snip I always thought that even IBM cut it real close when it came to fixing SMF records. I vaguely remember some ptf's coming out in last 1990's fixing a record. Since its been over 10 years my memory cannot come up with specifics other than I remember some. I agree that with out the doom sayers management would never have paid any attention (or very little). I know for sure my code for SMF record(s) reporting needed a few tweaks here and there. I would have hated to fix the reporting program I wrote in 197x as that was a program that even I was amazed at as to its efficiency. I am pretty sure the kludge that would have had to be redone would not have been pretty. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: very strange ISHELL behaviour
I have access to a test system in Dallas as well, and it appears to function correctly for me. Have you made any changes to the default configuration that they supplied? Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS 1.11 Dallas RDP system request (was very strange ISHELL behaviour)
I have access to the Dallas system as well. I'm assuming that you mean /u/ibmuser/.sh_history. It works for me, is there another one in another location that you want me to test? Sorry if things don't line up well when I paste them. step 1: File Directory Special_file Commands Help --- Directory List Select one or more files with / or action codes. If / is used also select an action from the action bar otherwise your default action will be used. Select with S to use your default action. Cursor select can also be used for quick navigation. See help for details. EUID=0 /u/ibmuser/ Type Filename Row 1 of 3 _ Dir . _ Dir .. e File .sh_history step 2 File Directory Special_file Commands Help - +---+ -- | Select Edit or Browse Options| | | S | Enter options for edit: | s used also select an a | Profile name . . . . | will be used. Select w | Initial macro . . . | so be used for quick n | | E | Select additional options:| | _ Edit or browse command line on bottom |Row 1 of 3 _ | _ Bypass this panel on edit | _ | | e | | | | +---+ just press enter and you get step 3 File Edit Edit_Settings Menu Utilities Compilers Test Help --- EDIT /u/ibmuser/.sh_history Columns 1 00072 Command === Scroll === PAGE ** * Top of Data ** ==MSG -CAUTION- Data contains invalid (non-display) characters. Use command ==MSG === FIND P'.' to position cursor to these ==MSG -Warning- The UNDO command is not available until you change ==MSG your edit profile using the command RECOVERY ON. 01 cd /u/ivp 02 etpval 03 etpvalc 04 ctof 05 man -ls 06 man ls 07 exit 08 cd /u/ivp 09 ctof 10 exit 11 cd /u 12 cd ivp 13 etpval 14 exit 15 cd /u/dasuser/das/adm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSF Authority Change with z/OS 1.9
When using the old parms, it's likely that they have not 'lost access but that they have changed their settings and can't see the output because of that. To be sure, when they are in the output queue, they should type the PREFIX command with no options. If they still can't see it, they should type H ALL If they STILL can't see it, then it could be that you have actually changed the parms from the previous release, and you just need to locate the actual parms that you are using, sometimes people will have steplibs, or another set of the parms will be in a linklist library that precedes the one you think you are using. It's usually something quite simple like that. The parms are pretty straightforward, and remember that they are first match oriented, so the first group that they match, is the one that they will use, it's not best match, just first match. If you still can't get this fixed after the above, send me you parms and the userid and the TSO authorizations of the user in question, (i.e. JCL, OPER, etc.) and I'll let you know what the problem was/is. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSF Authority Change with z/OS 1.9
Alan, Have you had the user do a WHO in SDSF and confirm that you are using the correct ISFPRM00? Maybe there is a default one shipped with the system you do not know you are picking up? Or perhaps you need to check on if the ISFPRM00 was compiled from before and the wrong version is in the LINKLST somewhere. I would look at the ISFGRP and SDSF member being used and make sure they match from before the upgrade. Lizette Hello group, I have another puzzler that I haven't solved yet. We've migrated from z/OS 1.7 to 1.9 and some people have lost the ability to view output that is in held class 5. This doesn't seem to be affecting everyone as there's lots of entries in class 5 and various jobs and I've only heard from two people. We're using the SDSF server with ISFPRM00 in a pds, not external security. Any clues how I can rectify this? The SDSF manual is a lot less clear on non-SAF security than it used to be. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ServerPac and HBBN700G problem (WAS OEM)
W dniu 2010-05-21 22:12, Steve Dover pisze: Friday afternoon, thought I was going to be done. I have the same problem. Freshly installed z/OS V1.11, buckets pulled and installed. Had hired help who ran into problems before he left, so I picked up where he left off. Had to run the HBBN700I job to back off previous run of HBBN700G, then reran 700G. Have all the same logs, with all the same messages. Was this problem ever resolved? Well, maybe. I've got several answers off-list (THANK YOU!). All of them did not resolve the problem, most of them simply gave up and omitted the OSMF and all related components. It seems that Simplify is as true for OSMF as Green for z10. (Explanation: green z10 consumes 50% more power. OSMF is meant to simplify management, but it requires singinicant amount of sysprog time to be installed). Of course YMMV, I'm sure that someone somewhere does use it. BTW: The tool is almost completely unintegrated with ServerPac. All the datasets EXCEPT WAS OEM and OSMF and Co are managed in organized way. RACFTGT job contains numerous mistakes (even obvious ones) and requires serious modifications. The worst thing I met and still not resolved is HBBN700G - the worst is lack of messages. The way of communication remains the Windows. That's very hard accusation, but justified IMHO g -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ZFS problems
Recently I first time IPLed z/OS 1.11. I followed IBM's recommendations and completely switched to ZFS filesystem (this is default in ServerPac). So long so good. However, possibly after some unclean system close (this is sandbox system) I had serious problems with IPL. OMVS could not initialize for approx. 50 minutes. I guess during the time a checking of ZFS structures had a place. A lng time. Imagine you have to restart your production system after some (i.e. power) failure. And you have more filesystems than ROOT. DUe to lack of OMVS no TCPIP communication was possible. Only console and (AFAIR) non-SNA terminals. sarcasm Is the above one of numerous enhancements of ZFS? /sarcasm -- 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.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ZFS problems
Radoslaw, this sounds like journal (log) replay issues. I guessing you had the root mounted read/write. You *really* don't want to be doing that - even on test systems, remount as r/w only for the time you need it (say for mkdir). zFS has had its share of latch contension issues, but I'd lean toward it attempting recovery. Shane ... On Sat, May 22nd, 2010 at 9:43 PM, R.S. r.skoru...@bremultibank.com.pl wrote: However, possibly after some unclean system close (this is sandbox system) I had serious problems with IPL. OMVS could not initialize for approx. 50 minutes. I guess during the time a checking of ZFS structures had a place. A lng time. Imagine you have to restart your production system after some (i.e. power) failure. And you have more filesystems than ROOT. DUe to lack of OMVS no TCPIP communication was possible. Only console and (AFAIR) non-SNA terminals. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Extrac ting BIND/ Link-edit date from a program object or load modul e
---snip An IDR is an IDR is an IDR. 'Translator' IDRs are not different in format from putative 'user' IDRs; nor do they appear in some canonical sequence that makes them distinguishable from others. That said, any competent HLASM programmer can retrieve existing ones or create and timestamp a new one. A number of ISVs have indeed succeeded in retrieving them in order to incorporate the information they contain in their own products' outputs. --unsnip- Dig out your old Linkage Editor PLM and check the record descriptions. IDRs have four different type of data, but a single physical record can only contain one of the types. Since I haven't looked at program objects, I won't dispute the point in that case. ---snip- Moreover, it has been a long time since the linkage editor extracted such information from translator-generated END statements; and the binder never did. (The historical use that CICS made of [different] information appended to END statements made this operation problematic early on.) They (and the translators, which associate them with object modules) have generated their own IDRs for decades. --unsnip Funny thing. My most recent PL/1 objects don't contain anything but ESD, TXT, RLD and END records. Where's the IDR? On my Assembler objects, it's there in the END record for all the world to see. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SDSF Authority Change with z/OS 1.9
All solved. There was a usermod to ISFUSER that was overlooked. IBM gave great guidance: The symptom looks like either the SDSF class and/or the JESSPOOL class is activated on the system. When either one of those 2 classes is activated, and when you have not customized the SDSF user exit, then the dummy SDSF user exit we shipped will direct SDSF to make decision on who can see which jobs using the external security instead of the ISFPRMxx. Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Saturday, May 22, 2010 6:11 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SDSF Authority Change with z/OS 1.9 Alan, Have you had the user do a WHO in SDSF and confirm that you are using the correct ISFPRM00? Maybe there is a default one shipped with the system you do not know you are picking up? Or perhaps you need to check on if the ISFPRM00 was compiled from before and the wrong version is in the LINKLST somewhere. I would look at the ISFGRP and SDSF member being used and make sure they match from before the upgrade. Lizette Hello group, I have another puzzler that I haven't solved yet. We've migrated from z/OS 1.7 to 1.9 and some people have lost the ability to view output that is in held class 5. This doesn't seem to be affecting everyone as there's lots of entries in class 5 and various jobs and I've only heard from two people. We're using the SDSF server with ISFPRM00 in a pds, not external security. Any clues how I can rectify this? The SDSF manual is a lot less clear on non-SAF security than it used to be. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Configuring HOSTNAME for OMVS segment
Chokalingam Ideally, you would be posting in IBMTCP-L rather than IBM-MAIN since that is where you will find the greater concentration of folk who know and use the IP component of z/OS Communications Server - and also TCP/IP for VM. I'm going to assume IPv4 from this point on. This is a tricky topic - mixed in with another tricky topic - so it's best to be very clear over what you have done. We have changed the IP address of our test mainframe ... First to clear away possibly incorrect terminology. An IP address belongs to an IP *interface*. An IP address does *not* belong to an IP node. You may have established a static VIPA and you may consider that this IP address represents the IP logic in the test LPAR, the IP node, to be referenced by applications which are necessarily associated with the IP node such as the SNMP agent. Or your IP node may have only one IP interface and so you have got into the habit of thinking of the interface address as belonging to the node - quite understandable. Actually whether the IP address is actually that of an interface or a static VIPA you logically associate with the node doesn't in fact affect the remaining discussion so very much. Incidentally, the above was neither of the trick topics! We have changed the IP address of our test mainframe and the DNS names for the same. So you have changed the IP address which you associate with the IP node and you have added an entry in the name server to which you refer which includes the new IP address and you have defined a name for it. You have removed the entry in the name server which contained the old address with which another name was associated. What do you mean by we check the hostname in OMVS segment still showing old DNS name ... ? and ... but MVS side it showing the new DNS name. ? In other words what command is it that you enter and what is the output. Or perhaps it was not a command but some other operation which reveals a name which you imagine is the name stored with the IP address in the name server. This is the first *tricky* topic: from where does the name in your tests come? A. Some operations in an IP context take an IP address and, using whatever information is provided in order to perform the translation of IP addresses into names, use the gethostbyaddr() API call for the translation. B. Other operations discover an IP address using the gethostid() API call and use that IP address, identified explicitly or by default as the PRIMARYINTERFACE and, using whatever information is provided in order to perform the translation of IP addresses into names, use the gethostbyaddr() API call for the translation. C. Yet other operations simply acquire the name using the gethostname() API call without any reference to IP addresses or, of course, information provided in order to perform the translation of IP addresses into names. All these operations now depend on the other *tricky* topic: where is your generically named TCPIP.DATA file? Incidentally, it is here that Patrick Lyon's extremely sparse contribution fits, possibly relevant since it highlights where the UNIX and MVS paths have a divergence. The relevance of the TCPIP.DATA file is that it contains the character string which satisfies the gethostname() API call as the HOSTNAME statement[1] - and - the statements used to access the name server - or a local file. There is a search order which, if you have customised your resolver function, can involve merging parameters from two data sets - I did say *tricky*! The search order is as follows: notes Base resolver configuration files - Resolver - GLOBALTCPIPDATA plus the first of the following% * Environment variable - RESOLVER_CONFIG * /etc/resolv.conf //SYSTCPD DD statement # x.TCPIP.DATA SYS1.TCPPARMS(TCPDATA) Resolver - DEFAULTTCPIPDATA TCPIP.TCPIP.DATA * only UNIX # x is userid for UNIX and userid/jobname/procname for MVS % If GLOBALTCPIPDATA used, the following are completely specified there: DomainOrigin/Domain NSInterAddr/NameServer NSPortAddr ResolverTimeOut ResolverUDPRetries ResolveVia Search SortList The following may be found in the search order data set: ALWAYSWTO DATASETPREFIX HOSTNAME LOADDBCSTABLES LOOKUP MESSAGECASE OPTIONS SOCKDEBUG SOCKNOTESTSTOR SOCKTESTSTOR TCPIPJOBNAME TCPIPUSERID TRACE RESOLVER TRACE SOCKET /notes You see that Patrick Lyon's /etc/resolver.conf file just about fits in here although it is more accurately /etc/resolv.conf. It is actually an extension of the TCPIP.DATA tricky topic to be sure whether the IP function uses the UNIX environment or the MVS environment. My notes on the resolver, from which the above notes were taken, have 17 - I just counted them - *unresolved* questions concerning confusion in what is stated in the manual. Just to muddy the water, I believe there are some commands which distort the story just given by insisting on performing name
Re: Of interest to the Independent Contractors on the list
On 21 May 2010 08:10, Binyamin Dissen bdis...@dissensoftware.com wrote: On Fri, 21 May 2010 06:43:42 -0400 Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: :Indeed. On the flip side, not every Y2K bug was worth fixing. At NSF :we had a monitor that showed the date as 19100; the only real effect :that bug had was to provoke the occasional chuckle. So it was smart enough to know that it needed 3 digits for the end part of the year, but then it concatenated the string '19' in front? One wonders who programmed such a thing (unless it was PL/I which would do that automatically). Typical C programming style combined with C library behaviour produced this in many many programs. I have a Windows fax program that came with a Dell machine in 1998 or so (called Focal Point - long out of business). It still runs fine, except that it cranks out the date as 19110. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
VSE with DB2 on zLinux
Has anyone had experience with z/VSE connected to DB2 on zLinux ? If yes, it would be much appreciated to get some performance information like number of queries per second or any other numbers. Thank you, Arye. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Getting BIND/LINK date out of load module members
First, LIBR is a program, not a proc (VSE defaults to PGM, not PROC, on the EXEC statement). LIBR is a VSE operating system component. LIBR can be used to catalog, for example, an OBJ module in to a VSE library: // EXEC LIBR,PARM='ACCESS SUBLIB=USER.PROD' CATALOG DDAR04.OBJ REPLACE=YES ...object module goes here... /+ /* / On the other hand, LNKEDT (the VSE linkage editor) is used to catalog an executable phase (VSE load module) to a VSE library: // JOB LNKEDT // LIBDEF PHASE,CATALOG=USER.PROD // OPTION CATAL PHASE DDAR04,* INCLUDE DDAR04 // EXEC PGM=LNKEDT / The lines between OPTION CATAL and EXEC LNKEDT are instructions to the linkage editor. This instructs it to create phase named DDAR04 from DDAR04.OBJ found in the system library search chain (something that z/OS does not have). The LIBDEF PHASE,CATALOG=USER.PROD JCL statement specifies the destination VSE library name, the the OPTION CATAL JCL statement instructs the linkage editor to catalog it's result to that library. Is this the same product library as is LIBR? Well, they are both part of VSE. And for all I know (I am not a systems programmer) LIBR could be used under the covers by LNKEDT. Anyway, as far as I know, these are the only two methods of placing a member in a VSE library. Even an application program would, I assume, call LIBR or LNKEDT to place something in a VSE library. Seems to me this standard of placing things in a library is a good thing. YMMV. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 5/21/2010 at 7:18 PM, in message 4bf730fe.6050...@ync.net, Rick Fochtman rfocht...@ync.net wrote: --snip- I am not interested in it being in the load module (or program object), though that may be useful for things other than what I am specifically concerned about. I am interested in it being in the directory (be it PDS or PDSE). Here is my specific concern. If a new module is to be implemented today (though perhaps bind/linked prior to today and then copied in to the load library today) I want to be able to verify for sure that it was done. Sometimes our production migration process has failed in that the actual of the load module to production was forgotten, or somehow failed, or something. In VSE I can do this: // EXEC LIBR LISTD SUBLIB=USER.PROD /* And I get a nice report of the members in the USER.PROD VSE library, like this: DIRECTORY DISPLAYSUBLIBRARY=USER.PROD DATE: 2010-05-21 TIME: 18:41 M E M B E R CREATION LAST BYTESLIBR CONT SVA A- R- NAME TYPE DATE UPDATE RECORDS BLKS STOR ELIG MODE ACCTCHEK PHASE02-02-20 08-06-04 35984 B 37 YES NO 31 ANY ACCTNO PHASE08-07-31 09-02-26 21080 B 22 YES NO 31 ANY ACDSTAT1 PHASE03-06-13 - -12344 B 13 YES NO 31 ANY ACDSTAT2 PHASE03-06-13 - -54064 B 55 YES NO 31 ANY ACHCVT PHASE07-07-25 07-08-28 24688 B 25 YES NO 31 ANY Is that not very useful? --unsnip- Frank, what you're asking for is not unreasonable. Unfortunately, directory entry data can vary from product and there are no set standards beyond the first 12 bytes. For example, what product created the members in this example? Does your LIBR proc use something from the same product family to create this listing? Do all those dates get appropriately updated when you move the member into USER.PROD? Is that move done by another piece of this Product family? There are just too many variables to be able to say that This product or program will give you a similar or equivalent listing. The high level of flexibility of z/OS and its predecessors is in part due to this lack of concrete standards. It's not always helpful for those of us that manage system resources, etc., but it's part of the evolution, whether we like it or not. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and
Re: VSE with DB2 on zLinux
We were doing this for a few years, but in fact actually moved to DB2 on Intel because we were having performance issues with Linux for System z. From what I've heard on the internet I think it was simply a Linux for z tuning issue, but the inhouse VSE/VM sysprogs and (distributed) Linux admins spent months trying to tune it, but in the end management directed them to just go to Intel. Frustrating, because I think if we'd contacted some outside experts we could have got it working; but... Anyway, we now actually have DB2 and Federation Server running on Intel, and we use Federation Server to access our Oracle (on Intel) databases. So we go z/VSE application - remote DB2 / Fed Server - Oracle. We get adequate performance, that's all I'll say. Of course that's only for one more week! A week from tonight we cut over to z/OS. So we'll have z/OS application - DB2 for z/OS - remote DB2 / Fed Server - Oracle. Wheee :-) I added an additional step because on z/OS the application address space communicates with the DB2 address space, which then communicates with the remote DB2 server. On VSE the application address space itself goes directly (using DRDA) to the remote server. I'd be glad to answer more specific questions, but I don't know how to get you numbers or statistics. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 On 5/22/2010 at 1:09 PM, in message aanlktimpzmbc3uu814k1n5evl32l0vjzr3l3c1xrf...@mail.gmail.com, Arye Shemer aryeshe...@gmail.com wrote: Has anyone had experience with z/VSE connected to DB2 on zLinux ? If yes, it would be much appreciated to get some performance information like number of queries per second or any other numbers. Thank you, Arye. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSE with DB2 on zLinux
This is very difficult to quantify, as it depends upon a great many things; the speed of the CP that z/VSE is running on, the speed of the IFL that Linux is running on, whether or not hipersockets is in use, the MTU size of the link, the release of z/VSE, the release of DB2 LUW, the number of rows in the query... and there's likely to be more that I can't think of right off the top of my head. I might suggest requesting reference accounts that have been through this process. On Sat, May 22, 2010 at 2:09 PM, Arye Shemer aryeshe...@gmail.com wrote: Has anyone had experience with z/VSE connected to DB2 on zLinux ? If yes, it would be much appreciated to get some performance information like number of queries per second or any other numbers. Thank you, Arye. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Rich Smrcina Velocity Software, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Enterprise Extender, z/OS 1.11
Linda Does Enterprise Extender still function with 1.11? Has there been an IBM announcement that says Enterprise Extender (EE) has been withdrawn? I would find this enormously surprising given the massive investment in new functions which can be found going from z/OS Communications Server release to release for EE - which, after much research and quite a bit of frustration with the level of IBM APAR documentation these days, I discover is the source of the FUD being put about by Brian Peterson and - although appearing only in Google and not the regular archives - Tom Longfellow. All this to say nothing of the ostrich egg that will be on my face for encouraging the customer where I work from time to time to rely upon EE for a major set of support functions within the network. Were you perhaps burned by the withdrawal of AnyNet SNA over IP a few releases back and so are driven quivering into a corner by any release movement involving SNA over IP? Recall that Enterprise Extender was the migration path provided - even if you were likely to lose an arm and a leg in the migration process - for AnyNet SNA over IP. It was the poor folk who saw the - theoretical - advantages of using AnyNet IP over SNA who suffered being cast into outer darkness with no migration support when they were cut off at the knees. Does either system require any service? In principle, in asking a question such as this one it's important to know which platform is in use supporting EE in your partner data center so that you can check compatibility. It need not be z/OS Communications Server. It could be one of a range of other IBM Communications Server products including the one which runs on Linux for System z or whatever the favourite name is this week. The other platforms are Windows and AIX and Linux on Intel architecture. Also we mustn't forget the AS/400 or again whatever the favourite name is this week. Then there are the non-IBM platform such as Microsoft's Host Integration Server (HIS) or Cisco's SNA Switching Services (SNASw). Actually I can't say the list is endless! But all of this is moot. EE is an architecture. This means that all the platforms work towards a common implementation agreed by all. Thus you are entitled to assume - and, after alarums and excursions thanks to Brian Peterson and Tom Longfellow, it is shown to be a valid assumption - that any implementation of EE at any level of supporting software with function quite happily with any other implementation of EE at any level of supporting software - point final! If there were really to be any showstoppers, your - or your partner's - regular search - due diligence - for high impact maintenance would have caught it. - So to what were Brian Peterson and Tom Longfellow referring with their FUD - less onerous in Tom's case, I'm happy to say, since he gave a clue where to go and find out what it might really have been all about. From Brian Peterson: I am pretty sure there was an incompatibility with EE across some number of z/OS releases. Your z/OS 1.4 system might NOT be able to connect to a new z/OS 1.11 system via EE. Last year, we almost had to delay our z/OS 1.10 implementation due to downlevel partnersas I recall. From Tom Longfellow: Search the IBM or Share websites for Marna Walle's excellent presentations on migration actions for z/OS 1.11. I think I remember a reference to a back- level EE connection problem. Thanks to Tom's hint to go looking into presentations on the web, I discovered that Brian had managed to convert the word compatibility in a section I found in the document, IBM Communications Server v6.4.0 for Linux (ppc64) INSTALLATION AND RELEASE NOTES on System p 5724-I33 entitled 1.3 Product compatibility where three APARs were listed into incompatibility - quite missing all the subtlety in what the purpose of the APARs was. After looking into - as far as I could - the three APAR fixes it was suggested could be installed in various z/OS releases in order to improve compatibility with the functions available in the release of Communications Server on Linux I found in two cases we were talking about some optional new function - in other words confusion caused by IBM striving to provide enhancements to a very much alive EE architecture! I hope you noticed that the words improve and enhancements were used there. We are absolutely ***not*** talking about showstoppers and - please correct me if I'm wrong - you had in mind showstoppers rather than the somewhat obscure facility such as Enterprise Extender connection network reachability awareness as implemented through the UNRCHTIM start option and operand of the PORT or GROUP (preferred) statement in the XCA major node - which I dread having to try to explain to the customer folk for whom I work from time to time in an education session concerning the design I have foisted on them. The point is that, for this function to work
Re: ZFS problems
You should mount the sysres zFS files read only (as you should have been doing with HFS also). But also make sure you have this in your zFS parms: romount_recovery=on/* see APAR OA22351 */ Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ On Sat, 22 May 2010 23:19:28 +1000, Shane Ginnane ibm-m...@tpg.com.au wrote: Radoslaw, this sounds like journal (log) replay issues. I guessing you had the root mounted read/write. You *really* don't want to be doing that - even on test systems, remount as r/w only for the time you need it (say for mkdir). zFS has had its share of latch contension issues, but I'd lean toward it attempting recovery. Shane ... On Sat, May 22nd, 2010 at 9:43 PM, R.S. r.skoru...@bremultibank.com.pl wrote: However, possibly after some unclean system close (this is sandbox system) I had serious problems with IPL. OMVS could not initialize for approx. 50 minutes. I guess during the time a checking of ZFS structures had a place. A lng time. Imagine you have to restart your production system after some (i.e. power) failure. And you have more filesystems than ROOT. DUe to lack of OMVS no TCPIP communication was possible. Only console and (AFAIR) non-SNA terminals. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ZFS problems
You have to wonder why this is even a consideration. The journal should be run automagically unless the customer chooses not to. In the unlikely event a filesystem is unmounted uncleanly *AND* the subsequent mount is changed from R/W to R/O, the decision not to run the journal should be the customers. Fail the mount unilaterally - what sort of a default is that ?. Especially for things like the root ... Shane ... On Sun, May 23rd, 2010 at 8:04 AM, Mark Zelden wrote: But also make sure you have this in your zFS parms: romount_recovery=on/* see APAR OA22351 */ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
