Quantcast
Channel: IBM Mainframe Computers Forums
Viewing all 8500 articles
Browse latest View live

Testing & Performance analysis :: RE: DD DUMMY & CPU TIME

$
0
0
Author: Rohit Umarjikar
Posted: Wed Dec 21, 2016 12:32 am (GMT 5.5)

I know what TS is asking here, my reply ain't different than what you say and that's why I say is a half fix dummying the output file instead of not producing it at all when not required anymore.
_________________
Regards,
Rohit Umarjikar
"Knowledge is knowing that a tomato is a fruit, but Wisdom is knowing not to put it in a fruit salad."icon_razz.gif


Testing & Performance analysis :: RE: DD DUMMY & CPU TIME

$
0
0
Author: Arun Raj
Posted: Wed Dec 21, 2016 12:38 am (GMT 5.5)

Your response seemed to suggest that, the OP is creating the data set in stepA and that he is trying to dummy it in stepB, which is not the case here.
_________________
Arun
----------------------------------------------------------------------------------------------------
Love is like an hourglass, with the heart filling up as the brain empties. -Jules Renard

Testing & Performance analysis :: RE: DD DUMMY & CPU TIME

$
0
0
Author: vasanthz
Posted: Wed Dec 21, 2016 12:44 am (GMT 5.5)

You would see difference in the EXCP(execute channel path macro call) values as there would be not writes happening to the DUMMY file.

The TCB would show decrease as no records are written and a minuscule difference in SRB as the device need not be allocated as it is DUMMIED out.

As for the CPU, like Bill mentioned the CPU variance in IO would be small compared to removing the logic on the program itself.
_________________
If you're going to do something tonight that you'll be sorry for tomorrow morning, sleep late.

Testing & Performance analysis :: RE: DD DUMMY & CPU TIME

$
0
0
Author: Phrzby Phil
Posted: Wed Dec 21, 2016 2:03 am (GMT 5.5)

The half fix may be the safest.

I once worked at an agency that required every functionality to be tested if any change was made to a program. Hence, some simple changes were just never made.
_________________
World Peace Through Frisbee.

CLIST & REXX :: RE: REXX DB2: Dynamic allocation of DB2.DSNLOAD

$
0
0
Author: Marso
Posted: Wed Dec 21, 2016 2:58 am (GMT 5.5)

Line 1 asks TSO to give a DD name to the DB2 load library,
Line 2 asks ISPF to add this DD to its LoadLIB,
Line 3 is supposed to run the REXX program, (program names are up to "8 bytes") usually the same program that actually uses DB2.

And don't forget to release the library once the program is over.

However, you may find that this library is already available to you, as there are almost certainly a few rexx tools already running on your site.

Testing & Performance analysis :: RE: DD DUMMY & CPU TIME

$
0
0
Author: Bill Woodger
Subject: Reply to: DD DUMMY & CPU TIME
Posted: Wed Dec 21, 2016 3:40 am (GMT 5.5)

Yes, there can be several stages. The DD DUMMY is a painless way of not actually getting the physical IOs, without the program requiring change, or being somehow changed by the now non-event - DD DUMMY is entirely transparent to a COBOL program. An easy first stage, being done as soon as possible.

I was once told, and have never verified, that putting buffers on DD DUMMY "allows the data to be ignored faster".

I think that all the CPU use within the IO routines stays, and the records are just finally not written. I think. I don't know.

Changing the program itself has at least two obvious potential stages. Remove the IO statements (and any checking associated with them). This is/should be transparent to the "business logic" in the program, but is a much larger change than just the DD DUMMY.

Then there is the clearing out of the processing associated with the creation of the records (again this can be staged). You may arrive at a point where there is still code remaining, but that it is bound to other processing in such a way that there's too great a risk of unintended consequence.

There is always a risk in leaving redundant code operating as well (it can trip future changes, analysis of the program, false impressions on problem-determination/impact-analysis.

Documenting, externally, such that the next person along should be aware, can mitigate the risks.

IBM Tools :: Are there any Freeware utilties for ibm mainframes

$
0
0
Author: johnmull
Subject: Are there any Freeware utilties for ibm mainframes
Posted: Wed Dec 21, 2016 8:29 am (GMT 5.5)

Are there any sites that contain freeware for z/os or mvs ? I have a couple to post out there if possible.

IBM Tools :: RE: Are there any Freeware utilties for ibm mainframes

$
0
0
Author: enrico-sorichetti
Subject: Reply to: Are there any Freeware utilties for ibm mainframes
Posted: Wed Dec 21, 2016 9:01 am (GMT 5.5)

www.cbttape.org
_________________
cheers
enrico
When I tell somebody to RTFM or STFW I usually have the page open in another tab/window of my browser,
so that I am sure that the information requested can be reached with a very small effort icon_cool.gif


JCL & VSAM :: RE: JES2 JEC: Use UNIX Pipes to Pass Data Between Concurrent Job

$
0
0
Author: Virendra Shambharkar
Subject: Reply to: JES2 JEC: Use UNIX Pipes to Pass Data Between Concurrent Job
Posted: Wed Dec 21, 2016 2:58 pm (GMT 5.5)

Hi,

When I try to create a UNIX pipe I am getting an error

IGD17501I ATTEMPT TO OPEN A HFS FILE FAILED,
RETURN CODE IS (00000081) REASON CODE IS (0594003D)

Below link mentions that it occurs "if attempting to
start the CAE Server on USS when the server logs directory has
not been created"

http://www-01.ibm.com/support/docview.wss?uid=swg1PM43917

Can somebody give pointers to how to create the CAE server or how to resolve this error .

Thanks in advance.
_________________
Virendra Shambharkar

JCL & VSAM :: RE: JES2 JEC: Use UNIX Pipes to Pass Data Between Concurrent Job

$
0
0
Author: Virendra Shambharkar
Subject: Reply to: JES2 JEC: Use UNIX Pipes to Pass Data Between Concurrent Job
Posted: Wed Dec 21, 2016 3:29 pm (GMT 5.5)

Sorry how to create the server log directory.
_________________
Virendra Shambharkar

JCL & VSAM :: RE: JES2 JEC: Use UNIX Pipes to Pass Data Between Concurrent Job

$
0
0
Author: Robert Sample
Posted: Wed Dec 21, 2016 6:12 pm (GMT 5.5)

Did you notice that the CAE error message applies ONLY to the DB2 Query Monitor Tool? That's what the APAR is about. If you decide to create the CAE server, read the installation guide for the DB2 Query Monitor Tool product and follow its directions.

In general, the return code X'81' and reason code x'0594003D' means that you are attempting to open a Unix file or directory that does not exist. This could mean that you actually are trying to open a non-existent file or attempting to navigate to a non-existent directory, or it could mean that the user id you are running the batch jobs under does not have appropriate Unix permissions to the file (or to one, or more, of the directories in the tree to the file).
_________________
TANSTAAFL

The first rule of code reuse is that the code needs to be worth re-using.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth

JCL & VSAM :: RE: JES2 JEC: Use UNIX Pipes to Pass Data Between Concurrent Job

$
0
0
Author: Virendra Shambharkar
Subject: Reply to: JES2 JEC: Use UNIX Pipes to Pass Data Between Concurrent Job
Posted: Wed Dec 21, 2016 7:48 pm (GMT 5.5)

Thanks.
I have created a new FIFO file using TSO OEDIT and I can see read and write permissions. I am trying to copy data from my mainframe dataset to this FIFO file and below are the permissions I can see:-


Command Filename Message Type Permission Audit Ext Fmat
------------------------------------------------------------------------------
new FIFO rw-rw-rw- fff--- ----

Do we need to get any special permission to use this FIFO UNIX file in z/OS and how do we get these permissions.

Thanks again.
_________________
Virendra Shambharkar

JCL & VSAM :: RE: JES2 JEC: Use UNIX Pipes to Pass Data Between Concurrent Job

$
0
0
Author: Robert Sample
Posted: Wed Dec 21, 2016 8:34 pm (GMT 5.5)

What user id does the batch job run under? And you didn't say anything about the directory tree -- if your batch user id doesn't have access to the entire directory tree, the error could occur due to it.

At this point, I recommend working with your site support group. You are not posting anywhere near enough data for us to help you on the forum, and the site support group will be able to see everything and help you resolve issues.
_________________
TANSTAAFL

The first rule of code reuse is that the code needs to be worth re-using.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth

JCL & VSAM :: RE: JES2 JEC: Use UNIX Pipes to Pass Data Between Concurrent Job

$
0
0
Author: Virendra Shambharkar
Subject: Reply to: JES2 JEC: Use UNIX Pipes to Pass Data Between Concurrent Job
Posted: Wed Dec 21, 2016 8:45 pm (GMT 5.5)

This is the directory structure I see where my ID starts with gID. I am also running the job with my ID only.

Pathname . : /u/g138818

Command Filename Message Type Permission Audit Ext Fmat
-------------------------------------------------------------------------------
. Dir rwxr-xr-x fff--- ----
.. Dir rwxr-xr-x fff--- ----
.sh_history File rw------- fff--- --s- ----
new FIFO rw-rw-rw- fff--- ----
******************************* Bottom of data ********************************
Do I need to get permission on this directory through some commands or updating the permission file?

Thanks for your help.
_________________
Virendra Shambharkar

JCL & VSAM :: RE: JES2 JEC: Use UNIX Pipes to Pass Data Between Concurrent Job

$
0
0
Author: Robert Sample
Posted: Wed Dec 21, 2016 9:13 pm (GMT 5.5)

Quote:
Do I need to get permission on this directory through some commands or updating the permission file?
In Unix System Services, if using OMVS you use the chmod command to change permissions; if using OEIS you use the menu to change permissions. Since Unix System Services interacts with the site security package (usually RACF, TOP SECRET, or ACF2), you cannot expect to "update the permission file" and have anything work.

And to answer the question, if you're just using your user id you should have the rights you need. What is the precise error message the batch job is giving you (we shouldn't have to ask for this -- you should have posted it when you first said the batch job is having a problem)? Are you using the fully qualified path in your batch job (/u/g138818/new FIFO)? Are you using quotes around the name in your JCL so the space in the file name isn't misinterpreted?

And terminology is critical in IT where similar terms may mean very different things. "GID" is group id and "UID" is user id in Unix System Services -- your home directory should be /u/userid which is NOT the group id; if you're using the group id for anything in your job then you are using the wrong field.
_________________
TANSTAAFL

The first rule of code reuse is that the code needs to be worth re-using.

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth


CLIST & REXX :: RE: REXX DB2: Dynamic allocation of DB2.DSNLOAD

$
0
0
Author: Pedro
Subject: Reply to: REXX DB2: Dynamic allocation of DB2.DSNLOAD
Posted: Wed Dec 21, 2016 10:56 pm (GMT 5.5)

Quote:
but 3rd command is asking for a 8 bytes long DSN(CLIST) name.


The 'asking' part is not clear to me. Can you post the messages that you receive?

Your stated requirement is to allocate dynamically. Your steps 1 & 2 do that. Step 3 tries to go beyond allocating and to actually invoke DB2. It is your invocation of DB2 that is not correct.

I think you need to provide the parameters that DB2 needs to start. Something like this (untested):
Code:
QUEUE 'RUN PROGRAM(mydb2prog) PLAN(mydb2plan)'     
QUEUE 'END'           
Address ispexec ,
    'SELECT CMD(DSN SYSTEM(DB2A)) '

_________________
Pedro Vera

Testing & Performance analysis :: RE: DD DUMMY & CPU TIME

$
0
0
Author: steve-myers
Posted: Thu Dec 22, 2016 1:32 am (GMT 5.5)

Well, I did try it. I thought I saw 50 million mentioned in this thread, but all I can actually find now is "millions." I couldn't get enough storage for 50 million, but I did try it for 10 million.

These were run under Hercules - 18.45 seconds to write 10,000,000 records to a data set, 1.06 seconds to "write" to DD DUMMY. The loop overhead was 0.10 seconds.

The program wrote a fixed record, so there was no record preparation time, so a real program will show higher times

Testing & Performance analysis :: RE: DD DUMMY & CPU TIME

$
0
0
Author: vasanthz
Posted: Thu Dec 22, 2016 1:37 am (GMT 5.5)

Nice research Steve, I wish there was a like button. How did you find the loop overhead. Just curious.
_________________
If you're going to do something tonight that you'll be sorry for tomorrow morning, sleep late.

Testing & Performance analysis :: RE: DD DUMMY & CPU TIME

$
0
0
Author: steve-myers
Posted: Thu Dec 22, 2016 2:33 am (GMT 5.5)

Code:
         L     3,COUNTER
         CPUTIME STORADR=STIME,CPU=MIC...
         BCT   3,*
         CPUTIME STORADR=ETIME,CPU=MIC...
         LG    3,ETIME
         SG    3,STIME
         STG   3,TEMP
         LM    0,1,TEMP
         D     0,=F'1000'

Since a BCT was used for the PUT loop, the overhead times had to be basically the same

DFSORT/ICETOOL :: SYMNAMES problem

$
0
0
Author: jacobdng
Subject: SYMNAMES problem
Posted: Thu Dec 22, 2016 7:47 am (GMT 5.5)

Please help to identify the problem.

JCL symbol:
Code:
//STEP1    EXEC PGM=ICETOOL                                             
//TOOLMSG   DD  SYSOUT=*                                               
//DFSMSG    DD  SYSOUT=*                                               
//SYMNAMES  DD *                                                       
NEXT-BUSINESS-DATE,C'20161221'                                         
//X0    DD DSN=&&X0,DISP=(,PASS),SPACE=(TRK,(200,60)),UNIT=SYSDA       
//SYM   DD DSN=&&CNST,DISP=(,PASS),SPACE=(TRK,(5,5)),UNIT=SYSDA         
//IN    DD *                                                           
AAAA                                                                   
//TOOLIN DD *                                                           
  COPY FROM(IN) TO(SYM) USING(CTR1)                                     
//CTR1CNTL DD *                                                         
  OUTFIL BUILD=(NEXT-BUSINESS-DATE)                                     
/*                                                                     
//STEP2    EXEC PGM=ICETOOL                                             
//TOOLMSG   DD  SYSOUT=*                                               
//DFSMSG    DD  SYSOUT=*                                               
//SYMNAMES  DD DSN=&&CNST,DISP=SHR                                     
//T0    DD DSN=&&T0,DISP=(,PASS),SPACE=(TRK,(200,60)),UNIT=SYSDA       
//VSAMF DD *                                                           
AAA                                                                     
/*                                                                     
//TOOLIN DD *                                                           
  COPY FROM(VSAMF) TO(T0)                                               
//                                                                     


Error Message:[quote]10.03.42 JOB03116 -JOBNAME STEPNAME PROCSTEP RC EXCP CPU SRB CLOCK
10.03.42 JOB03116 -ZBFCNT1J DELMON 00 10 .00 .00 .00
10.03.42 JOB03116 -ZBFCNT1J STEP1 00 37 .00 .00 .00
10.03.42 JOB03116 IEC141I 013-20,IGG0191A,ZBFCNT1J,TEST,SYMNAMES,755F,TASMA5,
814 SYS16357.T100341.RA000.ZBFCNT1J.CNST.H03
10.03.42 JOB03116 IEA995I SYMPTOM DUMP OUTPUT 815
815 SYSTEM COMPLETION CODE=013 REASON CODE=00000020
815 TIME=10.03.42 SEQ=17513 CPU=0000 ASID=008A
815 PSW AT TIME OF ERROR 075C1000 80D9F3B6 ILC 2 INTC 0D
815 NO ACTIVE MODULE FOUND
815 NAME=UNKNOWN
815 DATA AT PSW 00D9F3B0 - 4100302C 0A0D010D A7E5014B
815 AR/GR 0: 008FE990/00D9F6C0 1: 00000000/A4013000 [code]

The explanation of Reason Code 20:
Quote:
10.03.42 JOB03116 -JOBNAME STEPNAME PROCSTEP RC EXCP CPU SRB CLOCK
10.03.42 JOB03116 -ZBFCNT1J DELMON 00 10 .00 .00 .00
10.03.42 JOB03116 -ZBFCNT1J STEP1 00 37 .00 .00 .00
10.03.42 JOB03116 IEC141I 013-20,IGG0191A,ZBFCNT1J,TEST,SYMNAMES,755F,TASMA5,
814 SYS16357.T100341.RA000.ZBFCNT1J.CNST.H03
10.03.42 JOB03116 IEA995I SYMPTOM DUMP OUTPUT 815
815 SYSTEM COMPLETION CODE=013 REASON CODE=00000020
815 TIME=10.03.42 SEQ=17513 CPU=0000 ASID=008A
815 PSW AT TIME OF ERROR 075C1000 80D9F3B6 ILC 2 INTC 0D
815 NO ACTIVE MODULE FOUND
815 NAME=UNKNOWN
815 DATA AT PSW 00D9F3B0 - 4100302C 0A0D010D A7E5014B
815 AR/GR 0: 008FE990/00D9F6C0 1: 00000000/A4013000


Please help!

Viewing all 8500 articles
Browse latest View live