Re: Where are the allocation messages of a USS process?
Thanks Kirk for the pointer to the doc and others for pointing out the unavoidable complexing situations. One question to possibly avoid the problem of where to write the files with all their considerations: we have a Syslog Deamon running, can I have the messages sent to this place? That would be quite helpful. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Tuesday, May 13, 2014 17:39 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where are the allocation messages of a USS process? often the answer is nowhere. See this for a solution: http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.bpxb200%2Fjobpro.htm Kirk Wolf Dovetailed Technologies http://dovetail.com On Tue, May 13, 2014 at 6:32 AM, Vernooij, CP (SPLXM) - KLM kees.verno...@klm.com wrote: Hello group, We have some dataset problems with USS processes and are looking for the allocation messages. I mean the IGD101I SMS ALLOCATED TO DDNAME (DSNIWK02) DSN (SYS14131.T210019.RA000.XI1DMS1A.R0141149) STORCLAS (SCBATCH) MGMTCLAS () DATACLAS () VOL SER NOS= VIO and similar that you see in the message file of a job or STC or even in Syslog for an STC under MSTR. Where do these and other messages going for a USS process? A BPXAS STC is started for the process, but this only contains the messages for the BPXAS itself. Thanks, Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Issues while trying to install COD
Hi All, I'm trying to install COD in our machine. As per the COD installation guide, I have mounted the stand-alone tape in the tape drive and performed the LOAD process. Also i'm able to perform the initial steps (ie) using ICKDSF program to perform the initialization of volumes. The next stop is to restore the COD tape contents into the dasd volumes initialized. As per the guide, it should invoke the DFSMSdss program which is located as 3rd file in the tape. So i tried the LOAD process once again to invoke the DFSMSdss program. But it is again showing me the ICKDSF step only. So please suggest me how do i read the DFSMSdss program to restore COD tape contents. Please let me know if you need any other details. I'm using HMC, Operating system messages panel to perform these steps. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Buying desktop software from IBM
Personally, I thought there was only one English as she is spoken by HM! I spent 20 years in the US trying to teach Americans to speak English properly... but failed :-( And John - ow she cuttin dere by'e - there's always Newfoundland English!!! -Original Message- From: John Abell john.ab...@intnlsoftwareproducts.com To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU Sent: Wed, 14 May 2014 2:28 Subject: Re: Buying desktop software from IBM How odd that they didn't include the real one - Canadian English EH!! John T. Abell President International Software Products Tel: 800-295-7608 Ext: 224 International: 1-416-593-5578 Ext: 224 Fax: 800-295-7609 International: 1-416-593-5579 E-mail: john.ab...@intnlsoftwareproducts.com Web: www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith III Sent: Tuesday, May 13, 2014 6:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Buying desktop software from IBM In the checkout process, it wants to know my Communication Language and my Media Language. For the latter, choices include: Australian English British English Eastern European English English International English US English I'd be hard-pressed to choose among several of those.or to even imagine what Eastern European English is?! Anyone? Bueller? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFSORT/ICETOOL/ICEMAN: Grouping records
Hello, can you pls give me an hint about how to use DFSORT to perform the following? input dsn: FB-80 with: dsn tape volser --- 1 1234567890123456 dsn1 cart1 dsn2 cart1 dsn3 cart1 dsn4 cart1 dsn5 cart2 dsn6 cart2 dsn7 cart3 dsn8 cart3 dsn9 cart3 I want to an outfile grouped by tape volser like this: outfile for cart1 with: HSEND WAIT RECALL dsn1 HSEND WAIT RECALL dsn2 HSEND WAIT RECALL dsn3 HSEND WAIT RECALL dsn4 outfile for cart2 with: HSEND WAIT RECALL dsn5 HSEND WAIT RECALL dsn6 I've seached on Smart DFSORT Tricks manual and on DFSORT Application Programming Guide but so far I didn't find the way. Many thx, A.Cecilio -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMFPRM00 - MAXDORM
I have been using SMF logstreams for several years now. I just recently stumbled upon a REDBOOK reference that pointed me to a MAXDORM value recommendation of 0100 or less instead of the 3000 default for MANx datasets. My bad for not discovering this sooner. My questions are this: Has anyone experienced any issues with the 1 minute recommendation? Tried even lower with excellent results? Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DELETE VSAM COMPONENTS
Dennis, Thanks. It worked. I was able to delete the orphan (duplicate) DATA INDEX components from volume SYS013. The CLUSTER/DATA/INDEX which reside on another volume - SYS001 - is intact. To answer other questions. There is an existing CLUSTER/DATA/INDEX on another volume SYS001. They have the same name as the erroneous orphan components. I think the user must have done an NSCR on the original cluster - volume SYS013 - then re-defined the CLUSTER/DATA/INDEX on volume SYS001. Thanks to all who answered my post. On Tue, 5/13/14, Givens, Dennis W. dennis.giv...@cnasurety.com wrote: Subject: Re: DELETE VSAM COMPONENTS To: IBM-MAIN@LISTSERV.UA.EDU Received: Tuesday, May 13, 2014, 10:41 AM Willie, Had the same problem this past weekend. The ones I wanted deleted were not cataloged. Here is the job that worked for me. Hope it helps you as well. //STEP1 EXEC PGM=IDCAMS //DD1 DD VOL=SER=WSC001,UNIT=3390,DISP=OLD //SYSPRINT DD SYSOUT=* //SYSIN DD * DELETE NETVIEW.TME54.SUR01.DSITRCS.DATA FILE(DD1) VVR - CAT(CATALOG.WSC.MASTER) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Tuesday, May 13, 2014 12:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DELETE VSAM COMPONENTS Good Day Members, I am trying to delete the VSAM components - data and index - from a disk volume. The problem is that there is a CLUSTER along with the same DATA INDEX component names which reside on another voume. Is there a way deleting the errant components? Both volumes are SMS managed. Thanks in advance for your help. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DELETE VSAM COMPONENTS
Radoslaw, When I did the LISTCAT via ISPF 3.4 against the DATA/INDEX portion it kept displaying the volser -SYS001 - where good CLUSTER/DATA/INDEX reside eventhough I put the volser SYS013. On Tue, 5/13/14, R.S. r.skoru...@bremultibank.com.pl wrote: Subject: Re: DELETE VSAM COMPONENTS To: IBM-MAIN@LISTSERV.UA.EDU Received: Tuesday, May 13, 2014, 11:01 AM W dniu 2014-05-13 19:24, willie bunter pisze: Good Day Members, I am trying to delete the VSAM components - data and index - from a disk volume. The problem is that there is a CLUSTER along with the same DATA INDEX component names which reside on another voume. Is there a way deleting the errant components? Both volumes are SMS managed. If you don't feel comfortable: 1. Make a backup of the dataset, I mean the proper one. Use REPRO. Watch the messages and RC. 2. Just rename the proper dataset, that means rename cluster and both components names. Why? New names cannot be messed with orphaned component names. Now your data is safe. You can start main job. 3. Make sure those components are really orphaned, issue listcat. 4. Use DEL ...VVR, as Dennis suggested HTH -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Issues while trying to install COD
Re-initiate the IPL without touching the tape drive. If it's the third file, you'll need to initiate IPL three times to load SADSS. Please let us know if that's not documented in the guide that came with the COD. Subscribe Nallasivam.V , IBM-MAIN wrote: Hi All, I'm trying to install COD in our machine. As per the COD installation guide, I have mounted the stand-alone tape in the tape drive and performed the LOAD process. Also i'm able to perform the initial steps (ie) using ICKDSF program to perform the initialization of volumes. The next stop is to restore the COD tape contents into the dasd volumes initialized. As per the guide, it should invoke the DFSMSdss program which is located as 3rd file in the tape. So i tried the LOAD process once again to invoke the DFSMSdss program. But it is again showing me the ICKDSF step only. So please suggest me how do i read the DFSMSdss program to restore COD tape contents. Please let me know if you need any other details. I'm using HMC, Operating system messages panel to perform these steps. -- John Eells z/OS Technical Marketing IBM Poughkeepsieb ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Buying desktop software from IBM
W dniu 2014-05-14 00:50, Skip Robinson pisze: This list is fascinating both for inclusions and for omissions. I will defer humbly to Radoslaw for opinion on 'Eastern European English', [...] (Disclaimer: I can only guess author's intention) EE English could mean English with support for EE national characters, like polish ąćęłńóśżź and keyboard layouts, and maybe timezone, currency, etc. In the past there was MS Windows CE 3.1 (CentralEastern Europe), first version, which provide national characters (fonts, keyboard layout), but the whole interfface was English. Nowadays it's AFAIK available in any Windows version. -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
On Tue, May 13, 2014 at 7:24 AM, Scott Ford scott_j_f...@yahoo.com wrote: John, Are you speaking of Sub Address Space storage ? I've never heard of Sub Address Space storage. I can't figure out what you mean. What I meant was storage which is in a subpool, such as 130, which is automatically owned by the JSTCB (Job Step TCB) of the requesting TCB, and is kept around until that TCB, the JSTCB, goes through termination. This is usually the step (JOB or STC or TSU) ending. Regards, Scott -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
On Wed, 14 May 2014 06:50:09 -0500, John McKown wrote: I've never heard of Sub Address Space storage. I can't figure out what you mean. Try subspace group. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
Hello, I've noticed a strange dss behavior and want ask explanation: After I finished dss backup, I always received a message similar to this: 15.29.56 JOB31114 IEC205I ODD,BKDS,BACKUP,FILESEQ=1, COMPLETE VOLUME LIST, 870 870 DSN=BKUP.D003,VOLS=PT0541,TOTALBLOCKS=12122 Is the block counts reported the real tape blocks written to tape or something else? I've noticed that for BASIC PS and extended format PS, it is different,below is my testing: st_TIME end_TIMEbackup source data type VOLSER VTV size(mb)VTV size(comp)(mb) tape block size(KB) Total block count reported by DSS 11:31:4111:33:12Extended format compressed PT3968 1854.15 647.77 128 33879 11:33:1211:34:42Extended format compressed PT3974 1854.15 647.77 64 33879 11:34:4211:36:17Extended format compressed PT3976 1854.15 647.77 256 33879 12:22:5012:31:20Extended format PT4034 6280.18 371.56 128 223678 12:31:2012:39:35Extended format PT4043 6280.18 371.56 64 223678 12:39:3512:47:58Extended format PT4053 6280.18 371.56 256 223678 12:55:0912:58:34Basic PS,compressed PT4065 6273.86 360.15 128 49115 12:58:3413:03:06Basic PS,compressed PT4067 6274.57 367.9 64 98428 13:03:0613:05:59Basic PS,compressed PT4072 6273.51 355.32 256 24527 13:08:0713:11:37Basic PSPT4075 6273.86 360.15 128 49117 13:11:3713:16:00Basic PSPT4078 6274.57 367.9 64 98426 13:16:0013:19:04Basic PSPT4082 6273.51 355.52 256 24528 That is: For basic PS backup,I can change block size using BLKSIZE in JCL and the resulting block count reported by rmm and dss will match, the result is: Bigger block size, less block count,backup speed is much quicker But for extended PS backup,no matter what specified in JCL,the block count reported by dss will be same, and it does not match with what's recorded by rmm, and speed are same for whatever block size. Could you explain? regards Victor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DELETE VSAM COMPONENTS
On Wed, 14 May 2014 04:11:23 -0700, willie bunter wrote: Lizette, My answers to your questions are below: On Tue, 5/13/14, Lizette Koehler stars...@mindspring.com wrote: Is the catalog shared or unique? The catalog is unique Are you sure that some other catalog does not have these components? I would look at the VVR's for these components to determine what catalog they were once cataloged in. Of the top of my head, I can't remember how to do that, but perhaps someone else can offer suggestions. Review the list of volsers it is on. Make sure you have a unique uncataloged VSAM dataset. I did the LISTCAT and it shows that the CLUSTER/DATA/INDEX reside on VOLSER SYS001 Just to be sure. Is it ONLY on SYS001? VSAM components can have extents on multiple volumes. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
On Wed, May 14, 2014 at 7:47 AM, Shane Ginnane ibm-m...@tpg.com.au wrote: On Wed, 14 May 2014 06:50:09 -0500, John McKown wrote: I've never heard of Sub Address Space storage. I can't figure out what you mean. Try subspace group. I have some minimal knowledge of that, thanks to CICS using them. But I don't see where that has much to do with STORAGE OBTAIN, other than complicating things when storage needs to be shared between an key 8 and a key 9 program. I think that IBM is missing out on a possibility, due to TSO being moribund, of using a subspace group the way that CICS does in order to more securely separate the non-APF TSO commands from the APF authorized commands. Run them in separate subspace groups. I wonder what perversions I can get UNIX to perform using them? Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
From the MVS extended Addressability Manual …SA22-7618-08 A subspace is a specific range of storage in the private area of an address space, designed to limit the storage a program can reference. A program that is associated with a subspace cannot reference some of the private area storage outside of the subspace storage range; the storage is protected from the program. Whether a given range of private area storage is protected from a program associated with a subspace depends on whether the storage is: Eligible to be assigned to a subspace (or “subspace-eligible”) Assigned to a subspace Not eligible to be assigned to a subspace. You control these storage “states” through the IARSUBSP macro. Storage outside of the private area is not affected by subspaces. A program running in an address space can reference all of the storage associated with that address space. In this section, a program's ability to reference all of the storage associated with an address space is called full address space addressability. A program running with full address space addressability can reference storage in any of the three states: eligible to be assigned to a subspace, assigned to a subspace, or not eligible to be assigned to a subspace. A program that runs in an address space that owns subspaces also has full address space addressability. While running in a subspace, a program now has access to 64-bit private and shared storage. It can reference the 64-bit storage while in subspace mode and no longer needs to issue the BSG (Branch in Subspace Group) instruction to switch to the base mode to reference the 64-bit storage. A program running in a subspace can reference storage that is assigned to its own subspace and storage that is not eligible to be assigned to a subspace. It cannot reference storage that is eligible to be assigned to a subspace or storage that is assigned to a subspace other than the one in which the program is running. In other words, a subspace allows a program running in it to reference all of the storage associated with the address space except the private area storage that is eligible to be assigned to a subspace or assigned to another subspace. When storage is not eligible to be assigned to a subspace and not assigned to a subspace, it can be referenced by a program running in a subspace or a program running with full address space addressability. This storage can be referenced by all subspaces as well as by programs running with full address space addressability. An address space that owns subspaces is also called a “base space”. Figure 74 illustrates the concept of creating a subspace in base space ASID 23. From: john.archie.mck...@gmail.com Sent: Wednesday, May 14, 2014 9:09 AM To: IBM Mainframe Discussion List On Wed, May 14, 2014 at 7:47 AM, Shane Ginnane ibm-m...@tpg.com.au wrote: On Wed, 14 May 2014 06:50:09 -0500, John McKown wrote: I've never heard of Sub Address Space storage. I can't figure out what you mean. Try subspace group. I have some minimal knowledge of that, thanks to CICS using them. But I don't see where that has much to do with STORAGE OBTAIN, other than complicating things when storage needs to be shared between an key 8 and a key 9 program. I think that IBM is missing out on a possibility, due to TSO being moribund, of using a subspace group the way that CICS does in order to more securely separate the non-APF TSO commands from the APF authorized commands. Run them in separate subspace groups. I wonder what perversions I can get UNIX to perform using them? Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
Subspace groups are not secure. A program can freely reset their subspace group. If you play nicely, the subspace groups help. On Wed, 14 May 2014 08:09:02 -0500 John McKown john.archie.mck...@gmail.com wrote: :On Wed, May 14, 2014 at 7:47 AM, Shane Ginnane ibm-m...@tpg.com.au wrote: : : On Wed, 14 May 2014 06:50:09 -0500, John McKown wrote: : : I've never heard of Sub Address Space storage. I can't figure out what : you mean. : : Try subspace group. : : : :I have some minimal knowledge of that, thanks to CICS using them. But I :don't see where that has much to do with STORAGE OBTAIN, other than :complicating things when storage needs to be shared between an key 8 and a :key 9 program. : :I think that IBM is missing out on a possibility, due to TSO being :moribund, of using a subspace group the way that CICS does in order to more :securely separate the non-APF TSO commands from the APF authorized :commands. Run them in separate subspace groups. I wonder what perversions I :can get UNIX to perform using them? : : : : Shane ... : : -- : For IBM-MAIN subscribe / signoff / archive access instructions, : send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN : -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IFASMFR
Hi, Does anyone know why you cannot map 100, 101, 102 or 110 records with this macro? I'd like to be able to collect a subset of the DB2 and CICS records, possibly by subsystem or region, or even down to a thread or transaction because of volume. We are not using log streams yet. Thanks Dean Sent from my iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IFASMFR
Don't hold my feet to the fire, but I believe some of the records are defined in the products that generate them. Look in the DB2 and CICS manuals. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dno Sent: Wednesday, May 14, 2014 10:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IFASMFR Hi, Does anyone know why you cannot map 100, 101, 102 or 110 records with this macro? I'd like to be able to collect a subset of the DB2 and CICS records, possibly by subsystem or region, or even down to a thread or transaction because of volume. We are not using log streams yet. Thanks Dean Sent from my iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
supervisor state vs. problem state
What is the general opinion out there on what portion of CPU cycles should be spent in supervisor state? Is more than 50% a bad thing? Could having a logical processor to physical processor ratio of greater than 2 (e.g. 8 logicals in a 3 CP cec) be bad? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: supervisor state vs. problem state
On 5/14/2014 7:23 AM, Klein, Kenneth E wrote: What is the general opinion out there on what portion of CPU cycles should be spent in supervisor state? Is more than 50% a bad thing? I can't imagine 50% is either good or bad. It is what it is; entirely dependent on the nature of the programs you are running at any given time. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IFASMFR
On Wed, 14 May 2014 10:09:08 -0400, Dno snipers5...@gmail.com wrote: Hi, Does anyone know why you cannot map 100, 101, 102 or 110 records with this macro? I'd like to be able to collect a subset of the DB2 and CICS records, possibly by subsystem or region, or even down to a thread or transaction because of volume. We are not using log streams yet. Thanks Dean Some of the challenge with these data sources are variability and complexity (to start), as follows: 1) CICS CMF 110/1 has 'tailorable' transaction data (MCT-directed by site/region/version) that is mapped by corresponding DICTIONARY data. 2) DB2 101 (with certain ACCOUNTING TRACE type activation) has the potential to generate a continuation-like record if more than 10 packages occur - that must be mapped back to the primary record since not all fields are present in both. 3) DB2 102 data (at the IFCID level) is comprehensive and larger number of metrics than a bread-basket. 4) Additionally, such as MQ 116/1-2, similar condition to #2 above with continuation-like record generation, based on unique-queue activity. In summary, these are just too comprehensive data sources for simple-mapping, likely without post-processing once the data-records are decoded to map all 'related records' to one transaction instance/event. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: supervisor state vs. problem state
On Wed, 14 May 2014 07:28:51 -0700, Ed Jaffe wrote: On 5/14/2014 7:23 AM, Klein, Kenneth E wrote: What is the general opinion out there on what portion of CPU cycles should be spent in supervisor state? Is more than 50% a bad thing? I can't imagine 50% is either good or bad. It is what it is; entirely dependent on the nature of the programs you are running at any given time. It may also depend on the OS. I suspect Linux spends a smaller portion in supervisor state than z/OS. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
On Wed, May 14, 2014 at 8:59 AM, Binyamin Dissen bdis...@dissensoftware.com wrote: Subspace groups are not secure. A program can freely reset their subspace group. Another wonderful idea shot down by cruel reality. If you play nicely, the subspace groups help. Just blue skying, but I wonder how much it would cost to use them in a highly multi-threaded server to enhance reliability. Especially if the server, like CICS, ran user supplied transaction code. Or is the UNIX way of using separate processes, in separate address spaces, simply better - FSVO better. I know some UNIX people who are bemoaning the increased use of threads in a UNIX environment due to possible cross task memory corruption. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: supervisor state vs. problem state
Klein, Kenneth E wrote: What is the general opinion out there on what portion of CPU cycles should be spent in supervisor state? Is more than 50% a bad thing? Could having a logical processor to physical processor ratio of greater than 2 (e.g. 8 logicals in a 3 CP cec) be bad? I don't have an opinion, but I will observe that not all the time spent in supervisor state is overhead. A number of services used by the programs you use will run partly or entirely in supervisor state; in other words, a lot of that time can be productive work, and it should not be regarded as being only OS housekeeping. (How much of it is productive? It depends on your workloads.) -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IFASMFR
The 110's I am not sure about. To map the DB2 records, use //SYSLIBDD DISP=SHR,DSN=DB2.DSN910.ADSNMACS (vary according to desired version and your site's naming conventions) and DSNDQWST DSECT=YES,SUBTYPE=ALLType 100 DSNDQWAS DSECT=YES,SUBTYPE=ALLType 101 DSNDQWSP DSECT=YES,SUBTYPE=ALLType 102 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dno Sent: Wednesday, May 14, 2014 7:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IFASMFR Hi, Does anyone know why you cannot map 100, 101, 102 or 110 records with this macro? I'd like to be able to collect a subset of the DB2 and CICS records, possibly by subsystem or region, or even down to a thread or transaction because of volume. We are not using log streams yet. Thanks Dean Sent from my iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
automated response
Test message - out til Monday 7am - testing for Lowe's -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IFASMFR
Thanks for the feedback, I'll check the DB2 samplib as a starting point. Sent from my iPhone On May 14, 2014, at 11:07 AM, Charles Mills charl...@mcn.org wrote: The 110's I am not sure about. To map the DB2 records, use //SYSLIBDD DISP=SHR,DSN=DB2.DSN910.ADSNMACS (vary according to desired version and your site's naming conventions) and DSNDQWST DSECT=YES,SUBTYPE=ALLType 100 DSNDQWAS DSECT=YES,SUBTYPE=ALLType 101 DSNDQWSP DSECT=YES,SUBTYPE=ALLType 102 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dno Sent: Wednesday, May 14, 2014 7:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IFASMFR Hi, Does anyone know why you cannot map 100, 101, 102 or 110 records with this macro? I'd like to be able to collect a subset of the DB2 and CICS records, possibly by subsystem or region, or even down to a thread or transaction because of volume. We are not using log streams yet. Thanks Dean Sent from my iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: supervisor state vs. problem state
*ix systems in general, spend a higher proportion of time in supervisor state than z/OS. This is not a bad thing. The beans are merely counted differently. Much of what z/OS and is predecessors manage to charge back to a specific user is not done in *ix. CMG probably has some good reference materiel in the archives. Cheryl Watson would also have some good info. ISTR some old numbers (without attribution) of +/- 50% supervisor state for *ix systems and +/- 10% for z/OS and predecessors.** **These numbers are about 10 years old may no longer be accurate. snip On 5/14/2014 7:23 AM, Klein, Kenneth E wrote: What is the general opinion out there on what portion of CPU cycles should be spent in supervisor state? Is more than 50% a bad thing? I can't imagine 50% is either good or bad. It is what it is; entirely dependent on the nature of the programs you are running at any given time. It may also depend on the OS. I suspect Linux spends a smaller portion in supervisor state than z/OS. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT/ICETOOL/ICEMAN: Grouping records
Toni Cecil, It is quite easy to split the records into multiple files. You need to use OUTFIL processing. Since you are dealing with dataset names, I believe that your VOLSER name starts after 44 bytes as DSName can be a max of 44 bytes. So I assumed that the VOLSER starts at position 50. //STEP0100 EXEC PGM=SORT //SYSOUT DD SYSOUT=* //SORTIN DD * +1+2+3+4+5+6+ DSN1 CART1 DSN2 CART1 DSN3 CART1 DSN4 CART1 DSN5 CART2 DSN6 CART2 DSN7 CART3 DSN8 CART3 DSN9 CART3 //CART1DD SYSOUT=* //CART2DD SYSOUT=* //CART3DD SYSOUT=* //SYSINDD * OPTION COPY INREC BUILD=(C'HSEND WAIT RECALL ',1,44,81:50,8) OUTFIL FNAMES=CART1,INCLUDE=(81,5,CH,EQ,C'CART1'),BUILD=(1,80) OUTFIL FNAMES=CART2,INCLUDE=(81,5,CH,EQ,C'CART2'),BUILD=(1,80) OUTFIL FNAMES=CART3,INCLUDE=(81,5,CH,EQ,C'CART3'),BUILD=(1,80) //* or alternatively you can use the following control cards too if you need to build the output differently for each output file. //SYSINDD * OPTION COPY OUTFIL FNAMES=CART1,INCLUDE=(50,5,CH,EQ,C'CART1'), BUILD=(C'HSEND WAIT RECALL ',1,44,80:X) OUTFIL FNAMES=CART2,INCLUDE=(50,5,CH,EQ,C'CART2'), BUILD=(C'HSEND WAIT RECALL ',1,44,80:X) OUTFIL FNAMES=CART3,INCLUDE=(50,5,CH,EQ,C'CART3'), BUILD=(C'HSEND WAIT RECALL ',1,44,80:X) //* Further if you have any questions please let me know Thanks, Kolusu DFSORT Development From: Toni Cecil acbi...@gmail.com To: IBM-MAIN@listserv.ua.edu, Date: 05/14/2014 02:25 AM Subject:DFSORT/ICETOOL/ICEMAN: Grouping records Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Hello, can you pls give me an hint about how to use DFSORT to perform the following? input dsn: FB-80 with: dsn tape volser --- 1 1234567890123456 dsn1 cart1 dsn2 cart1 dsn3 cart1 dsn4 cart1 dsn5 cart2 dsn6 cart2 dsn7 cart3 dsn8 cart3 dsn9 cart3 I want to an outfile grouped by tape volser like this: outfile for cart1 with: HSEND WAIT RECALL dsn1 HSEND WAIT RECALL dsn2 HSEND WAIT RECALL dsn3 HSEND WAIT RECALL dsn4 outfile for cart2 with: HSEND WAIT RECALL dsn5 HSEND WAIT RECALL dsn6 I've seached on Smart DFSORT Tricks manual and on DFSORT Application Programming Guide but so far I didn't find the way. Many thx, A.Cecilio -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Buying desktop software from IBM
I should have factored in the 'media' reference. Not what the lingo sounds like, what it looks like. Countries in Africa that use English for official purposes all sport (usually many) indigenous languages that typically use a Roman alphabet extensively enriched with diacritics to represent specific phonic or tonal variations. Meanwhile English is written in a standard way--despite the insanity of English orthography in general. ;-( . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: R.S. r.skoru...@bremultibank.com.pl To: IBM-MAIN@LISTSERV.UA.EDU, Date: 05/14/2014 04:23 AM Subject:Re: Buying desktop software from IBM Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU W dniu 2014-05-14 00:50, Skip Robinson pisze: This list is fascinating both for inclusions and for omissions. I will defer humbly to Radoslaw for opinion on 'Eastern European English', [...] (Disclaimer: I can only guess author's intention) EE English could mean English with support for EE national characters, like polish ąćęłńóśżź and keyboard layouts, and maybe timezone, currency, etc. In the past there was MS Windows CE 3.1 (CentralEastern Europe), first version, which provide national characters (fonts, keyboard layout), but the whole interfface was English. Nowadays it's AFAIK available in any Windows version. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
supervisor state vs. problem state
What is the general opinion out there on what portion of CPU cycles should be spent in supervisor state? Is more than 50% a bad thing? Could having a logical processor to physical processor ratio of greater than 2 (e.g. 8 logicals in a 3 CP cec) be bad? What is a reasonable rate for SIGP (Signal processor) instructions? Our rate is in the thousands. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: supervisor state vs. problem state
Comments interspersed. From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Klein, Kenneth E Sent: Wednesday, May 14, 2014 3:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: supervisor state vs. problem state What is the general opinion out there on what portion of CPU cycles should be spent in supervisor state? Is more than 50% a bad thing? --- See my previous reply to Gil. I would consider this a bad thing on a z/OS box. On an *IX box, not necessarily. The beans are counted differently and stuff that z/OS charges back to a user, *IX boxes just account for as overhead (i.e. supervisor state). The RMF workload activity report should be able to give you some help here. Could having a logical processor to physical processor ratio of greater than 2 (e.g. 8 logicals in a 3 CP cec) be bad? --- PR/SM overhead grows dramatically after 3:1 logical to physical. CPU times increase due to cache flushing in the processor (aka context switching). Your comment above equates to 2.67:1 I have run for several years with a 3:1 with minimal issues IMO, the 2.67 to 1 is OK. YMMV. What is a reasonable rate for SIGP (Signal processor) instructions? Our rate is in the thousands. --- Don't know. The most probable answer is it depends. IO configuration, processor enablement for IO interrupts. Logical to physical processors,... all have a role to play HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IFASMFR
As noted the mapping support is in a macro that is owned by the component not by the operating system. OTOH: There is no reason why IFASMFR can not have support for these records by internally calling the needed DSNQWS* macro. By having a dummy macro under the Operating System FMID (and supplying a SUPing copy of the Macro in the Component) the request to expand types 100-102 without DB2 would just issue use the dummy version and not issue an error while expanding the records via IFASMFR when you have DB2 installed. At 11:13 -0400 on 05/14/2014, Dno wrote about Re: IFASMFR: Thanks for the feedback, I'll check the DB2 samplib as a starting point. Sent from my iPhone On May 14, 2014, at 11:07 AM, Charles Mills charl...@mcn.org wrote: The 110's I am not sure about. To map the DB2 records, use //SYSLIBDD DISP=SHR,DSN=DB2.DSN910.ADSNMACS (vary according to desired version and your site's naming conventions) and DSNDQWST DSECT=YES,SUBTYPE=ALLType 100 DSNDQWAS DSECT=YES,SUBTYPE=ALLType 101 DSNDQWSP DSECT=YES,SUBTYPE=ALLType 102 Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dno Sent: Wednesday, May 14, 2014 7:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IFASMFR Hi, Does anyone know why you cannot map 100, 101, 102 or 110 records with this macro? I'd like to be able to collect a subset of the DB2 and CICS records, possibly by subsystem or region, or even down to a thread or transaction because of volume. We are not using log streams yet. Thanks Dean Sent from my iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
Victor, IEC205I gets the TOTALBLOCKS from system control blocks. It should match what rmm records (gets it from same place.. Actually it depends on access method and whether that method maintains the block count fields. EXCP does not and the application must maintain it. The block count is application block count sent to the device. what is on the tape depends on the tape device Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
Prior to 3480's with IDRC the physical block size on tape corresponded to the block size sent across the channel by MVS and the maximum tape data transfer rate was invariably bounded by the physical tape drive speed and the relation mean-data-rate B/sec = percent-of-tape-used-for-data x drive-transport-speed in/sec x density B/in, and the shorter the physical blocks, the greater the number of Inter-Record-Gaps IRGs) resulting in lower effective tape utilization and lower effective transfer rate. Prior to 6250 bpi recording technology, tape media and drive reading reliability generally dictated physical block sizes considerably less than 32KiB. My recollection is that the 6250bpi drives were the first to be consistently reliable enough to make using a block size of ~32KiB reasonable from a tape performance viewpoint (other resources could still be constraining factors). At that block size, effective tape media utilization at 6250bpi was still only about 94%, but MVS block size limits prevented going larger. The greater 38KiB density and greater reliability of 3480's increased the significance of tape lost to IRGs again, but the introduction of hardware compression on 3480's and its successors took the physical tape utilization issue out of the hands of MVS and programmers by forcing data into 256KiB physical super-blocks on the tape hardware level regardless of MVS's concept of block size. Use of larger block sizes today on MVS reduces the system and application overhead by managing fewer I/O buffers and initiating fewer channel programs to transfer the same amount of data, but it does not affect physical tape utilization andI would not expect the effect to be as dramatic as in the old days when a really bad MVS physical block size could easily elongate program run time and physical tape usage by a factor of 10 or more when over 90% of the physical tape was consumed by IRGs (and this fact was periodically rediscovered by some application programmer). The DFDSS manuals may not emphasize the default 256KiB MVS tape block size because that support is over a decade old and the only thing that should be reading a DFDSS tape is a compatible version of DFDSS. I would at least hope that none of the DFDSS JCL examples imply that BLKSIZE is recommended or a wise idea for tape output DDs. I still remember seeing the HOLD data on the PTF that added 256KiB block support to DFDSS -- It was critical to know that once that support was added, that the DFDSS used at a DR site or on a recovery system or on your stand-alone IPL tapes had to also be at the new level in order to restore from the generated backup tapes. Joel C. Ewing On 05/13/2014 11:04 PM, Ed Gould wrote: Skip: Our IBM SE (30+ years ago) wrote an orange manual (how many remember those?), About blocksize and tape. It pretty much said that use of a 32K blocksize as optimum for channel and tape utilization (this was 6250 BPI IIRC). Jim (our SE has retired) after serving time at the WSC and out in San Jose. But through the years the best thruput as to always code 32K for job where performance is needed. Of course with new technology I expect that the device that can handle 256K blocksize be used. I have often disliked the DFDSS manuals for not being straight forward in their documentation. I don't think DFSMS does the right thing with blksize=0 for tape, my memory is obsolete here but it used to be 16K when blocksize eq zero is used. Ed On May 13, 2014, at 6:25 PM, Skip Robinson wrote: We had some issues a while back with VSM performance. I did research and experiments with various block sizes for tape data sets. Questions on IBM-MAIN and doc reading yielded some answers--though not necessarily solutions. -- Tape output is generally faster with larger block sizes. That's easydemonstrate by coding ever larger block sizes. EXCP count and elapsed time will both decrease. -- You can't just increase output block size willy-nilly. A program thatuses a traditional DCB is limited to 32K bytes per block. To exceed that value, a program must employ DCBE, which is not hard to use but requires coding changes. -- If you attempt to code 32K block size in JCL for a program with DCB,the value will be ignored and revert to 32K. You might miss that fact because there's no message. Your tape management product (CA-1, RMM, etc.) will show you the actual block size of a file. -- Some IBM utilities are coded with DCBE to enable 32K block size.Others are not. Doc for each utility should indicate the maximum allowable output block size. -- DFSMSdss Storage Administration has this to say: If the DCB keyword BLKSIZE is specified on the DD statement for tape, it must be in the range of 7,892 through 262,144. If the DCB keyword BLKSIZE is specified on the DD statement for DASD, it must be in the range of 7,892 through 32,760. So DFDSS uses DCBE and can write 256K blocks. In my testing, a job ran quite a bit faster
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
On May 14, 2014, at 5:31 PM, Joel C. Ewing wrote: Prior to 3480's with IDRC the physical block size on tape corresponded to the block size sent across the channel by MVS and the maximum tape data transfer rate was invariably bounded by the physical tape drive speed and the relation mean-data-rate B/sec = percent-of-tape-used-for-data x drive-transport-speed in/sec x density B/in, and the shorter the physical blocks, the greater the number of Inter-Record-Gaps IRGs) resulting in lower effective tape utilization and lower effective transfer rate. Prior to 6250 bpi recording technology, tape media and drive reading reliability generally dictated physical block sizes considerably less than 32KiB. My recollection is that the 6250bpi drives were the first to be consistently reliable enough to make using a block size of ~32KiB reasonable from a tape performance viewpoint (other resources could still be constraining factors). At that block size, effective tape media utilization at 6250bpi was still only about 94%, but MVS block size limits prevented going larger. The greater 38KiB density and greater reliability of 3480's increased the significance of tape lost to IRGs again, but the introduction of hardware compression on 3480's and its successors took the physical tape utilization issue out of the hands of MVS and programmers by forcing data into 256KiB physical super-blocks on the tape hardware level regardless of MVS's concept of block size. Use of larger block sizes today on MVS reduces the system and application overhead by managing fewer I/O buffers and initiating fewer channel programs to transfer the same amount of data, but it does not affect physical tape utilization andI would not expect the effect to be as dramatic as in the old days when a really bad MVS physical block size could easily elongate program run time and physical tape usage by a factor of 10 or more when over 90% of the physical tape was consumed by IRGs (and this fact was periodically rediscovered by some application programmer). The DFDSS manuals may not emphasize the default 256KiB MVS tape block size because that support is over a decade old and the only thing that should be reading a DFDSS tape is a compatible version of DFDSS. I would at least hope that none of the DFDSS JCL examples imply that BLKSIZE is recommended or a wise idea for tape output DDs. I still remember seeing the HOLD data on the PTF that added 256KiB block support to DFDSS -- It was critical to know that once that support was added, that the DFDSS used at a DR site or on a recovery system or on your stand-alone IPL tapes had to also be at the new level in order to restore from the generated backup tapes. Joel C. Ewing Joel: But this was how long ago? The DFDSS doc should have been update by now. no? Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IFASMFR
The CICS SMF records can be mapped via SDFHMAC(DFHMN*) macros. But be aware that, by default, since CICS TS 3.2, CICS SMF records are written in a compressed format. The only part of a compressed 110 record that is not compressed is the SMF record header (DFHMNSMF), which contains the usual fields for system-id and job-name. You can sift 110 records by z/OS system or CICS region (job-name) by reading the uncompressed 110 header, but no more than that without de-compressing the records (using z/OS Data Compression and Expansion Services (CSRCESRV) ), or to process the performance data. You'd be better off using a utility that has the ability to de-compress and read CICS SMF records instead of re-inventing the wheel. See CICS Operations and Utilities and CICS Performance Guide, or the documentation of any brand X monitoring / reporting software (e.g. MXG). Ant. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Barry Sent: Thursday, 15 May 2014 12:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IFASMFR On Wed, 14 May 2014 10:09:08 -0400, Dno snipers5...@gmail.com wrote: Hi, Does anyone know why you cannot map 100, 101, 102 or 110 records with this macro? I'd like to be able to collect a subset of the DB2 and CICS records, possibly by subsystem or region, or even down to a thread or transaction because of volume. We are not using log streams yet. Thanks Dean Some of the challenge with these data sources are variability and complexity (to start), as follows: 1) CICS CMF 110/1 has 'tailorable' transaction data (MCT-directed by site/region/version) that is mapped by corresponding DICTIONARY data. 2) DB2 101 (with certain ACCOUNTING TRACE type activation) has the potential to generate a continuation-like record if more than 10 packages occur - that must be mapped back to the primary record since not all fields are present in both. 3) DB2 102 data (at the IFCID level) is comprehensive and larger number of metrics than a bread-basket. 4) Additionally, such as MQ 116/1-2, similar condition to #2 above with continuation-like record generation, based on unique-queue activity. In summary, these are just too comprehensive data sources for simple-mapping, likely without post-processing once the data-records are decoded to map all 'related records' to one transaction instance/event. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
On 05/14/2014 07:03 PM, Ed Gould wrote: On May 14, 2014, at 5:31 PM, Joel C. Ewing wrote: Prior to 3480's with IDRC the physical block size on tape corresponded to the block size sent across the channel by MVS and the maximum tape data transfer rate was invariably bounded by the physical tape drive speed and the relation mean-data-rate B/sec = percent-of-tape-used-for-data x drive-transport-speed in/sec x density B/in, and the shorter the physical blocks, the greater the number of Inter-Record-Gaps IRGs) resulting in lower effective tape utilization and lower effective transfer rate. Prior to 6250 bpi recording technology, tape media and drive reading reliability generally dictated physical block sizes considerably less than 32KiB. My recollection is that the 6250bpi drives were the first to be consistently reliable enough to make using a block size of ~32KiB reasonable from a tape performance viewpoint (other resources could still be constraining factors). At that block size, effective tape media utilization at 6250bpi was still only about 94%, but MVS block size limits prevented going larger. The greater 38KiB density and greater reliability of 3480's increased the significance of tape lost to IRGs again, but the introduction of hardware compression on 3480's and its successors took the physical tape utilization issue out of the hands of MVS and programmers by forcing data into 256KiB physical super-blocks on the tape hardware level regardless of MVS's concept of block size. Use of larger block sizes today on MVS reduces the system and application overhead by managing fewer I/O buffers and initiating fewer channel programs to transfer the same amount of data, but it does not affect physical tape utilization andI would not expect the effect to be as dramatic as in the old days when a really bad MVS physical block size could easily elongate program run time and physical tape usage by a factor of 10 or more when over 90% of the physical tape was consumed by IRGs (and this fact was periodically rediscovered by some application programmer). The DFDSS manuals may not emphasize the default 256KiB MVS tape block size because that support is over a decade old and the only thing that should be reading a DFDSS tape is a compatible version of DFDSS. I would at least hope that none of the DFDSS JCL examples imply that BLKSIZE is recommended or a wise idea for tape output DDs. I still remember seeing the HOLD data on the PTF that added 256KiB block support to DFDSS -- It was critical to know that once that support was added, that the DFDSS used at a DR site or on a recovery system or on your stand-alone IPL tapes had to also be at the new level in order to restore from the generated backup tapes. Joel C. Ewing Joel: But this was how long ago? The DFDSS doc should have been update by now. no? Ed Well granted it is hard to find and much more complicated than I remembered, but this feature was incorporated into z/OS 1.12 and DFSMSdss Storage Administration manual for z/OS 1.12 does have under Chapter 1 Introduction..., Dumping data efficiently, Space Considerations the following paragraph relating to DUMP output: The default block size for output records that are written to tape is the optimum block size for the output device (262 144 is the maximum). You can change this default to 32 760 by using the installation options exit routine. See the discussion of system-determined block size in z/OS DFSMS Using Data Sets for a description of the optimum block sizes of the supported tape devices. The DFDSS manual doesn't explicitly say what the default value is because it is dependent on the specific tape device type (or installation exits) and apparently the optimum tape device block size is part of z/OS Large Block Interface support and not part of DFDSS (which makes sense when you think about it). Since DFDSS does not control what the actual values are, you have to go to a non-DFDSS manual to find a table of the actual optimum values (z/OS DFSMS Using Data Sets, Chapter 21 Specifying and Initializing Data Control Blocks, Selecting Data Set Options, Block Size). This is not a tidbit of information that the average user needs to know to use DFDSS successfully, so perhaps it is OK that it takes some digging to locate. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: supervisor state vs. problem state
Could having a logical processor to physical processor ratio of greater than 2 (e.g. 8 logicals in a 3 CP cec) be bad? In my opinion, it depends on the box you're running on. We ran a z196 at a 4:1 ratio. The result was that up to 1.5% of all cpu consumed on that box across all apars was spent in PR/SM (according to the SMF70 records) when the box was running at 100% for hours. Nevertheless, the work got done. Eventually. An LPAR with a low weight in that situation could take up to 30s for a TSO response at WLM importance2. The same workload ran on a z9 before, in a 3:1 ratio. In that case, the SMF70 records for the box were showing less than 1% overall cpu consumed in PR/SM. TSO response was still bad :-( Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
