COBOL V5.2
Hi, We are testing out COBOL V5.2 and have found several problems. Just wondering how many of you are running COBOL V5.2 and if you are having a similar experience. Thanks, Gary -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zOS 1.13 – CPU latent demand
Thanks for the reply Scott. You are correct, we only have 1 CPU. We have many DB2 threads with high unaccounted for time. One of the possible reasons for this could be that zOS/DB2 is waiting on CPU. I was hoping to use the CPU Activity report to determine if this is contributing to unaccounted for time. I have added another snapshot below of a different LPAR during a busy time. Please help me undstand the diffence between LPAR BUSY and MVS BUSY. Does the difference indicate this LPAR was waiting for the CPU? How can I quantify this? The differnect between the two values? Any insight you can give me to understand how to interpret this report would be appreciated. Or if you can suggest a different report/method. C P U A C T I V I T Y PAGE1 z/OS V1R13 SYSTEM ID DEVL START 09/29/2014-13.45.00 INTERVAL 000.14.59 RPT VERSION V1R13 RMF END 09/29/2014-14.00.00 CYCLE 2.000 SECONDS CPU2818 CPC CAPACITY53SEQUENCE CODE 000437E7 MODEL V01CHANGE REASON=N/A HIPERDISPATCH=NO H/W MODEL M05 ---CPU--- TIME % LOG PROC --I/O INTERRUPTS-- NUM TYPEONLINELPAR BUSYMVS BUSY PARKED SHARE % RATE % VIA TPI 0CP 100.0021.9580.01 -- 14.0 962.6 16.14 TOTAL/AVERAGE 21.9580.01 14.0 962.6 16.14 SYSTEM ADDRESS SPACE AND WORK UNIT ANALYSIS -NUMBER OF ADDRESS SPACES- ---DISTRIBUTION OF IN-READY WORK UNIT QUEUE-- QUEUE TYPES MIN MAX AVG NUMBER OF 0 10 20 30 40 50 60 70 80 90 100 WORK UNITS (%) ||||||||||| IN80 100 89.2 IN READY 0 58 6.7 = N 9.9 = N + 110.6 OUT READY 0 12 0.2 = N + 2 6.2 OUT WAIT 00 0.0 = N + 3 4.3 = N + 5 9.0 LOGICAL OUT RDY00 0.0 = N + 1022.1 LOGICAL OUT WAIT 57 80 68.5 = N + 1515.2 = N + 20 7.8 ADDRESS SPACE TYPES= N + 30 8.9 = N + 40 3.3 BATCH 14 2.4 = N + 60 1.8 STC 117 124119.5 = N + 80 0.4 TSO 33 35 34.0 = N + 100 0.0 ASCH 00 0.0 = N + 120 0.0 OMVS 24 2.0 = N + 150 0.0
Re: zOS 1.13 – CPU latent demand
Thanks for the reply Martin. I have checked paging and it is very low. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
zOS 1.13 – CPU latent demand
Hello, I am trying to understand how to utilize the RMF CPU report so that I can evaluate utilization of our CP and latent demand. The publications on this report I have read, indicate that when LPAR Busy MVS Busy, this is an indication of latent demand. In the report below, this is the case (45.85 49.68). However, if you look at the Partition Data Report, the CP was only at 77.11%. Why wasn’t PROD able to obtain the 49.68% needed? Any input appreciated. Thanks, Gary C P U A C T I V I T Y z/OS V1R13 SYSTEM ID PROD START 09/25/2014-08.00.00 INTERVAL 000.14.59 RPT VERSION V1R13 RMF END 09/25/2014-08.15.00 CYCLE 2.000 SECONDS CPU2818 CPC CAPACITY53SEQUENCE CODE 000437E7 MODEL V01CHANGE REASON=N/A HIPERDISPATCH=NO H/W MODEL M05 ---CPU--- TIME % LOG PROC --I/O INTERRUPTS-- NUM TYPEONLINELPAR BUSYMVS BUSY PARKED SHARE % RATE % VIA TPI 0CP 100.0045.8549.68 -- 73.1 946.8 5.87 TOTAL/AVERAGE 45.8549.68 73.1 946.8 5.87 P A R T I T I O N D A T A R E P O R T PAGE z/OS V1R13 SYSTEM ID PROD START 09/25/2014-08.00.00 INTERVAL 000.14.59 RPT VERSION V1R13 RMF END 09/25/2014-08.15.00 CYCLE 2.000 SECONDS MVS PARTITION NAMEPRODNUMBER OF PHYSICAL PROCESSORS 1 GROUP NAMECMIGRP IMAGE CAPACITY 50 CP 1 LIMIT 50 NUMBER OF CONFIGURED PARTITIONS 4 AVAILABLE 17 WAIT COMPLETION NO DISPATCH INTERVAL DYNAMIC - PARTITION DATA - -- LOGICAL PARTITION PROCESSOR DATA -- -- AVERAGE PROCESSOR UTILIZATION PERCENTAGES - MSU -CAPPING-- PROCESSOR- DISPATCH TIME DATA LOGICAL PROCESSORS --- PHYSICAL PROCESSORS -- NAME S WGT DEFACT DEF WLM% NUM TYPE EFFECTIVE TOTAL EFFECTIVETOTAL LPAR MGMT EFFECTIVE TOTA PROD A 7300 24 NO 0.01 CP00.06.51.842 00.06.52.642 45.7645.85 0.09 45.76 45.85 DEVL A 140 12 11 NO47.21 CP00.03.14.172 00.03.14.514 21.5821.61 0.04 21.58 21.61 TECH A552 1 NO 0.01 CP00.00.24.572 00.00.25.1312.73 2.79 0.06 2.73 2.79 TEST A748 3 NO 0.01 CP00.00.56.233 00.00.56.7306.25 6.30 0.06 6.25 6.30 *PHYSICAL* 00.00.04.972 0.55 0.55 - - - TOTAL 00.11.26.821 00.11.33.990 0.80 76.32 77.11 G R O U P C A P A C I T Y R E P O R T PAGE z/OS V1R13 SYSTEM ID PROD START 09/25/2014-08.00.00 INTERVAL 000.14.59 RPT VERSION V1R13 RMF END 09/25/2014-08.15.00 CYCLE 2.000 SECONDS GROUP-CAPACITY PARTITIONSYSTEM -- MSU -- WGT CAPPING - ENTITLEMENT - NAME LIMITDEF ACT DEF WLM% ACT% MINIMUM MAXIMUM CMIGRP 50 DEVL DEVL 1211 140 NO47.2 43.2 7 12 PROD PROD 024 730 NO 0.00.0 36 50 TECH TECH 2 155 NO 0.00.0 2 2 TEST TEST 8 374 NO 0.00.0 3 8 --- -- TOTAL 39 999 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS 1.13 Owner for Java files
Hello, I was given the task of applying maintenance to z/OS 1.13 using a documented procedure and all was going well, however, some of the PTFs did not apply because I was not a super user UID(0). So, I had the guy who usually does the applies submit the job and this applied the remaining PTFs. However, when I was looking at some of the JAVA files, I now notice that the owner is now my UID: File owner . . . . . : (3011) Group owner . . . . . : TECH(9) Where before the owner and group was: File owner . . . . . : HZSPROC(0) Group owner . . . . . : OMVSGRP(1) There are likely other files from other PTFs where I am now the owner. Is this going to cause a problem running the system. Do I need to fix this? Thanks in advance for your input. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS 1.13 ADRDSSU ECB WAIT
Hi, I am trying to determine why our data set dump job (ADRDSSU) runs longer on some days. Here is the type of dump being performed: DUMP DATASET(INCLUDE(**) - EXCLUDE( - SYS1.VVDS.** - SYS1.VTOCIX.** ) - BY((DSCHA,EQ,YES))) - STORGRP(PRDBAT) - OUTDD(OUT01D,OUT01T) - ADMIN OPTIMIZE(4) SPHERE TOL(ENQF) WAIT(0,0) Using Omegamon, I have produced the following report. Which indicates that ECB WAIT is the primary wait reason. I understand this is likely a voluntary wait by the program. Is there a way to determine why these waits would be issued and why they are such a large part of the elapsed time? Waiting on I/O to post? Shouldn't I also see time listed for DISK . ACTIVE? Any input appreciated. +-+ | JOB = P9725451 JES NUMBER = 11741 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = .51 S | | FROM 02:55 TO 04:36 ON 06/14/14 ELAP =1:41 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 4:18 M 4.2|- . . . . . . . . . .| |ECB WAIT 39:14 M 38.6|===. . . . . . .| |WAITING FOR CPU 27:08 M 26.7|-- . . . . . . . .| |JOB ELAPSED TIME 1:41 H| +-+ +-+ | JOB = P9725451 JES NUMBER = 18116 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = .81 S | | FROM 04:35 TO 06:03 ON 06/16/14 ELAP =1:28 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 3:00 M 3.4|- . . . . . . . . . .| |ECB WAIT 53:09 M 60.0| . . . .| |WAITING FOR CPU 10:42 M 12.1| . . . . . . . . .| |TAPE 0803 QUE 4:29 M 5.0|-- . . . . . . . . . .| |JOB ELAPSED TIME 1:28 H| +-+ +-+ | JOB = P9725451 JES NUMBER = 04485 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = 1.45 S | | FROM 04:55 TO 07:11 ON 06/17/14 ELAP =2:16 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 3:34 M 2.6|- . . . . . . . . . .| |ECB WAIT 1:27 H 64.1| . . . .| |WAITING FOR CPU 13:29 M 9.9|---. . . . . . . . . .| |TAPE 0801 QUE 8:55 M 6.5|-- . . . . . . . . . .| |TAPE 0802 QUE 8:43 M 6.4|-- . . . . . . . . . .| |JOB ELAPSED TIME 2:16 H| +-+ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.13 ADRDSSU ECB WAIT
I set PLOTMIN(0) so we can see all the wait reasons (below). Is all the ECB WAIT time attributable to waiting on I/O to post complete? I still don't understand why this would be such a large amount of the elapsed time. I would think disk and tape active would be the larger part. +-+ | JOB = P9725451 JES NUMBER = 11741 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = .51 S | | FROM 02:55 TO 04:36 ON 06/14/14 ELAP =1:41 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 4:18 M 4.2|- . . . . . . . . . .| |ECB WAIT 39:14 M 38.6|===. . . . . . .| |WAITING FOR CPU 27:08 M 26.7|-- . . . . . . . .| |TAPE 0800 QUE 4:09 M 4.0|- . . . . . . . . . .| |TAPE CM0167 0805 QUE 3:44 M 3.6|- . . . . . . . . . .| |TAPE CM0167 0805 ACT 2:40 M 2.6|- . . . . . . . . . .| |TAPE 0800 ACT 2:12 M 2.1|. . . . . . . . . . .| |TAPE MOUNT PENDING 1:08 M 1.1|. . . . . . . . . . .| |WAITING FOR MVS LOCK 48.04 S.7|. . . . . . . . . . .| |DISK BATP01 2010 ACT 20.59 S.3|. . . . . . . . . . .| |DISK BATP02 2110 ACT 18.30 S.3|. . . . . . . . . . .| |DISK BSMP00 2208 ACT 13.72 S.2|. . . . . . . . . . .| |DISK BATP07 2013 ACT 11.43 S.1|. . . . . . . . . . .| |ECB WAIT (W/ STIMER) 11.43 S.1|. . . . . . . . . . .| |DISK BATP06 2112 ACT 11.43 S.1|. . . . . . . . . . .| |DISK BATP03 2011 ACT 11.43 S.1|. . . . . . . . . . .| |DISK BSMP01 2308 ACT 6.86 S.1|. . . . . . . . . . .| |DISK BCKP07 200D ACT 6.86 S.1|. . . . . . . . . . .| |DISK BATP11 2015 ACT 4.57 S.0|. . . . . . . . . . .| |DISK BATP09 2014 ACT 4.57 S.0|. . . . . . . . . . .| |DISK BATP04 2111 ACT 2.28 S.0|. . . . . . . . . . .| |DISK BATP10 2114 ACT 2.28 S.0|. . . . . . . . . . .| |DISK BCKP02 210A ACT 2.28 S.0|. . . . . . . . . . .| |DISK BCKP04 210B ACT 2.28 S.0|. . . . . . . . . . .| |DISK BCKP06 210C ACT 2.28 S.0|. . . . . . . . . . .| |DISK BATP05 2012 ACT 2.28 S.0|. . . . . . . . . . .| |DISK SQPP01 2205 ACT 2.28 S.0|. . . . . . . . . . .| |JOB ELAPSED TIME 1:41 H| +-+ !CANDLE CORP. - REPORT V420 06/17/14 9.44.02 PAGE 2 COPYRIGHT (C) 1982-2009 CANDLE CORPORATION. ALL RIGHTS RESERVED. +-+ | JOB = P9725451 JES NUMBER = 18116 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = .81 S | | FROM 04:35 TO 06:03 ON 06/16/14 ELAP =1:28 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 3:00 M 3.4|- . . . . . . . . . .| |ECB WAIT 53:09 M 60.0| . . . .| |WAITING FOR CPU 10:42 M 12.1| . . . . . . . . .| |TAPE 0803 QUE 4:29 M 5.0|-- . . . . . . . . . .| |TAPE CM0425 0806 QUE 4:11 M 4.7|- . . . . . . . . . .| |TAPE CM0425 0806 ACT 3:16 M 3.7|- . . . . . . . . . .| |TAPE 0803 ACT 2:49 M 3.1|- . . . . . . . . . .| |TAPE MOUNT PENDING 1:15 M 1.4|. . . . . . . . . . .| |WAITING FOR MVS LOCK 27.44 S.5|. . . . . . . . . . .| |ECB WAIT (W/ STIMER) 13.72 S.2|. . . . . . . . . . .| |DISK BSMP00 2208 ACT 13.72 S.2|. . . . . . . . . . .| |DISK BATP08 2113 ACT 11.43 S.2|. . . . . . . . . . .| |DISK BATP02 2110 ACT 11.43 S.2|. . . . . . . . . . .| |DISK BATP11 2015 ACT 9.14 S.1|. . . . . . . . . . .| |DISK BATP05 2012 ACT 9.14 S.1|. . . . . . . . . . .| |DISK BATP09 2014 ACT 6.86 S.1|. .
Re: Is it possible to write an exit for ADRDSSU to capture backup information?
Radoslaw, I know the difference between ADRDSSU and HSM. We are a small shop and I don't see HSM in our future. It would be very difficult to justify, plus we simply don't need all that functionality. We have daily and weekly backups, so capturing the data would not be monumental. Other application uses of ADRDSSU are the developers responsibility. Lizette, I'll have to take a second look at ISMF. Can you point me to a panel that would list the datasets that exist on my backups created with ADRDSSU? Donald, thanks for the example, I will consider this approach. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is it possible to write an exit for ADRDSSU to capture backup information?
Thanks for all the replies. I am evaluating the idea of providing an ISPF dialog for generation of restore jobs. I would need to capture the information required to list available backups for a dataset and generate the restore JCL. One option is to parse the backup output using the SDSF REXX interface, but there is the possibility of failure when IBM changes the output format and messages. We do not have the REXX compiler so performance is also a concern. So, I was wondering if and exit might be more efficient approach. I am not too concerned about supporting the exit as we have multiple associates on our team that are capable. My main concern was the availability and complexity of devloping such an exit. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Is it possible to write an exit for ADRDSSU to capture backup information?
Is it possible to write an exit for ADRDSSU to capture backup information? If so, anyone have an example they would be willing to share? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OpenPGP Encryption
Currently, our OpenPGP encryption is done using a Windows server and the IPSwitch WS_FTP Client software. Configuration displays from the client indicate that we are using RSA, DSA and DH keys with sizes of 1024 and 2048 bits. Cipher algorithms include AES-256, Triple-DES, BLOWFISH and CAST5. We would like to start supporting OpenPGP encryption on our Z10 BC (2098-E10) mainframe running z/OS 1.13. I am having some difficulty understanding what hardware is required to support this. I have been reviewing the Redbook, Encryption Facility for z/OS V1.2 OpenPGP Support. It leads me to believe that the CPACF embedded processor that comes standard with the Z10 will handle the Cipher algorithms (except perhaps CAST5). But what about the key algorithms (RSA, DSA, DH)? Do I need additional hardware to handle those? Does it depend on the key size? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
