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

COBOL Programming :: RE: Dynamic output file creation in cobol using BPXWDYN

$
0
0
Author: Robert Sample
Subject: Reply to: Dynamic output file creation in cobol using BPXWDYN
Posted: Thu Jun 15, 2017 11:47 pm (GMT 5.5)

How do you know BPXWDYN worked correctly? Try
Code:
DISPLAY RETURN-CODE
after the call to BPXWDYN. If it is not zero, then the call did NOT work and (most likely) your allocated data set wasn't allocated. And since you didn't bother with file status (which should be a mortal sin for professional COBOL programmers such as those posting on this web site), you have no idea if the OPEN worked or not, if the WRITE worked or not, and if the CLOSE worked or not.

In other words, by your lack of error checking you have no way of knowing whether ANYTHING you did worked. If you decide to post anything else, we'll want to see RETURN-CODE after the call to BPXWDYN as well as the file status code for the OPEN, WRITE, and CLOSE statements. And if any of the four values are not zero, then you CANNOT tell us you have a "successful job run".

And, by the way, either the code you posted has a typo (BPXDWYN is what you are calling whereas BPXWDYN is the name of the IBM module) or the explanation for your results is calling the wrong program and NOT doing any error checking.
_________________
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


COBOL Programming :: RE: Dynamic output file creation in cobol using BPXWDYN

$
0
0
Author: smileheal
Posted: Fri Jun 16, 2017 12:16 am (GMT 5.5)

Hi Robert, thanks for the feedback.

I called BPXWDYN in my pgm. Apology 4 the typo.

I had set the RC from the call and following is the display.

77 WS-DYN-RC PIC S9(08) COMP-5.
CALL BPXWDYN USING WS-ALLOC-STRING RETURNING WS-DYN-RC.

RC1 :- 000000002N

COBOL Programming :: RE: Dynamic output file creation in cobol using BPXWDYN

COBOL Programming :: RE: Dynamic output file creation in cobol using BPXWDYN

$
0
0
Author: Robert Sample
Posted: Fri Jun 16, 2017 12:24 am (GMT 5.5)

The return code is -25, which means the fifth key failed the parse. So you need to display WS-ALLOC-STRING and find out what is wrong with the fifth key. Since the code you posted didn't have a space after CATALOG and before LRECL(10), the system is probably telling you CATALOGLRECL(10) Is invalid but you need to display WS-ALLOC-STRING to be sure.

And the fact you got a non-zero return code from BPXWDYN means that your statement about the job successfully running in your first post is rubbish -- the dynamic allocation failed so everything after that failed.
_________________
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

DB2 :: Identify top 30 big tables or indexes in db2 mainframe

$
0
0
Author: ashek15
Subject: Identify top 30 big tables or indexes in db2 mainframe
Posted: Fri Jun 16, 2017 10:01 am (GMT 5.5)

Hi All

Could any one pls let me know how can I find out top 30 tables and indexes in terms of sizes in a db2 environment?

Thanks.
_________________
I am a DB2 and IMS DBA

SYNCSORT :: RE: Reduce CPU Times for Join Sort

$
0
0
Author: santoshn
Posted: Fri Jun 16, 2017 11:09 am (GMT 5.5)

Nic Clouston wrote:
By default JOINKEYS sorts both data sets (they are not "files") unless told not to by the SORTED keyword - which I do not see in your control statements.


Thanks let me try using Sorted keyword.

SYNCSORT :: RE: Reduce CPU Times for Join Sort

$
0
0
Author: Abid Hasan
Posted: Fri Jun 16, 2017 12:12 pm (GMT 5.5)

Hello,

santoshn wrote:
...
This job is one of more expensive jobs so we are checking if any alternative can be implemented to reduce CPU times.
Both the files are unloads for tables so they are sorted with a default order.
....


Adding my two pennies worth!

a. Kindly explain 'expensive' as per 'your site standards'; by that what I meant was, 3 min. CPU time - may not really be very expensive when we are talking about 'large amount of data' running into millions/billions of records. For fewer records - yes, that can be called as expensive.

b. If you really want to dig deeper, look at the SORTMSG output for SYNCSORT, the WER messages will be segregated into 3 parts-
i. Processing for first JOINKEYS statement
ii. Processing for second JOINKEYS statement
iii. Processing for SORT statements (COPY, OUTFIL etc.)

On looking through them you should be able to make out 'how much' resources were used at each leg of *SORT processing. I do not have a SYNCSORT manual at hand currently, but I am pretty sure there is a keyword that can help generate additional diagnostic information; and if you're feeling chivalrous, dig through the SMF records, they will give you even more information on processing data (SMF logging for *SORT should be active for this data to be written). Skimming through it should give you a clear idea on which strip of *SORT is consuming 'more', is it just the data or is it something in the code.

If you're not happy with *SORT JOINKEYS, AND the data is already sorted, go ahead, write a COBOL file-balancing code; in either case - JOINKEYS/COBOL, you're reading both datasets top-down, only difference being - in case of COBOL you expect the data to be SORTED, whereas JOINKEYS does just that for you.

Btw, looking at the way the JOINKEYS statement has been set-up - I have a strong feeling that your data is not SORTED.


If none of it works out (and you still think your SORT is costly), write to Alissa (SYNCSORT/MFX development team) or Kolusu (DFSORT development team), both of them are extremely helpful and very-very knowledgeable in this area. They will surely be able to guide you.
_________________
Thanks.

DFSORT/ICETOOL :: RE: Include/omit with "ALL" parameter

$
0
0
Author: mgl
Subject: Reply to: Include/omit with "ALL" parameter
Posted: Fri Jun 16, 2017 2:37 pm (GMT 5.5)

Many thanks for your posts and specialy to RahulG31 and Sergeyken.
I am sorry, i didn't saw this explonation in the book and i always work with method 2.

Have a great end of day, Michel.


COBOL Programming :: RE: Dynamic output file creation in cobol using BPXWDYN

$
0
0
Author: smileheal
Posted: Fri Jun 16, 2017 3:38 pm (GMT 5.5)

Hi Robert, thanks 4 the valuable feedback.

Have corrected the string command to lave space between Catlog & LRECL.
Also used FREE Command before allocating the same DD Name to the subsequent files.

It is working fine now with expected result.

COBOL Programming :: RE: Dynamic output file creation in cobol using BPXWDYN

$
0
0
Author: Robert Sample
Posted: Fri Jun 16, 2017 6:01 pm (GMT 5.5)

Good to hear you got it working.
_________________
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

IBM Tools :: RE: OPC - job preconditions

$
0
0
Author: David Robinson
Posted: Fri Jun 16, 2017 9:08 pm (GMT 5.5)

Not 100% sure as I don't have a TWS system to hand, but I'm pretty sure the audit trail shows special resources becoming (un)available. Option 10 off the main menu IIRC, or you can also run it in batch.

SYNCSORT :: RE: Reduce CPU Times for Join Sort

$
0
0
Author: magesh23586
Subject: Reply to: Reduce CPU Times for Join Sort
Posted: Sat Jun 17, 2017 11:10 pm (GMT 5.5)

Remove following statements.
Code:

OUTFIL FNAMES=SORTOUT,                                             
BUILD=(1:1,1623)


I dont think the data is in sorted order, if it is in sorted order, specify SORTED,NOSEQCK in Joinkeys statement.
_________________
Regards,
Magesh

CA Products :: Easytrive Redefine

$
0
0
Author: vidyaa
Subject: Easytrive Redefine
Posted: Mon Jun 19, 2017 6:01 pm (GMT 5.5)

Hi,

Am trying to redefine a file variable in easytrieve but it is not getting aligned properly

Ex: File 16 to 18 position I have the record 06A. Am defining as below

Code:

DEPT             16   3 A     HEADING ('DPT')     
DEPTMENT         16   2 A                         
DEPT-A1          18   1 A                         

but writing the output I should have

DEPT = 06A
DEPTMEN = 06
DEPT-A1 = A

Instead I have

DEPT = 06A
DEPTMEN = 06
DEPT-A1 = C --> this is the value from the second record which has 06C and takes the value from the next next record for tha DEPT-A1 alone instead of the same record.

Am not sure what is missing here where any redefine issue or some thing else.
_________________
Thanks & Regards,
Vidya

COBOL Programming :: RE: Dynamic output file creation in cobol using BPXWDYN

$
0
0
Author: steve-myers
Posted: Mon Jun 19, 2017 7:18 pm (GMT 5.5)

I have no idea what the designers of OS/360 were actually thinking, but I suspect they were thinking they did not want application programmers to run into the problems the topic starter had when they did not provide dynamic allocation in OS/360.

As most of us know, TSO for OS/360 had a primitive dynamic allocation. There were a multitude of problems, most of them because TSO dynamic allocation was serialized using the same locks as JCL allocation, so if JCL allocation was working it blocked TSO allocation. This meant a TSO user had to wait for JCL allocation to complete.

The ALLOCATE and FREE commands, with their multitude of options illustrate the problems. TSO ALLOCATE and FREE, though they have been enhanced over the years, are little changed from the ALLOCATE and FREE commands for OS/360 TSO. The enhancements since OS/360 TSO are rarely used.

MVS, of course, has had dynamic allocation from the beginning, but it's mainly targeted at Assembler programmers. Most Assembler programmers find it difficult to use. Quite honestly, having observed its use over the years, I find dynamic allocation misused rather than properly used. The biggest problem is message support when a problem is encountered. It's usually done poorly; all too often mysterious error codes from dynamic allocation are presented to the end user, and even then presented in a fashion that make it difficult to use the available documentation.

The BPXWDYN function gives some clues.

First, BPXWDYN has never been part of the mainline z/OS product. Its documentation, such as it is, is not in any mainline z/OS document. I suspect most BPXWDYN users would not know where its documentation is located, much less actually use its documentation. I can recall, some years ago, spending several hours trying to find its documentation. Few people would guess where its documentation is hidden, much less deduce the rational that placed the documentation where it is.

Second, the character strings used with BPXWDYN are loosely based on the ALLOCATE and FREE TSO commands. I suppose this is a complement to the designers of the ALLOCATE command in 1970 or so. BPXWDYN does not use the sophisticated string parser used by TSO to examine the ALLOCATE and FREE commands so its message support when there is a syntax error is non-existent; this is a problem the topic starter encountered. The parser used in BPXWDYN seems to acknowledge many alternates accepted in TSO and commonly used by users of the TSO ALLOCATE and FREE commands, but these seemed to be programmed into the parser rather than unintentioned byproducts of the TSO parser. An example: the official syntax in TSO is FILE(xxx), but many TSO users found the OS/360 TSO parser accepted F(xxx) because there were no other keywords in the OS/360 ALLOCATE command that started with F, and lazy bums that we are we still use F(xxx) Eventually, of course, TSO ALLOCATE was changed to accept the more correct DDNAME(xxx) syntax. Regardless, BPXWDYN appears to use FI(xxx) and DD(xxx) as its official short cuts.

Third, the official documentation does not say BPXWDYN can be used in Cobol, though we all know, as does the topic starter, that it can be used in Cobol and some other high level languages such as C, as documented.

COBOL Programming :: Validate if a Value from the file is numeric

$
0
0
Author: balacsv2
Subject: Validate if a Value from the file is numeric
Posted: Mon Jun 19, 2017 11:52 pm (GMT 5.5)

I am reading a comma delimited file which comes from another vendor using unstring.I have a field from the file which could have values with the decimal point for ex.95.6 .I am receiving the field from the input file with the declaration

05 WS-PERCENT PIC X(06) JUST RIGHT

I need to check if WS-PERCENT which comes from the vendor is numeric.After receiving the field as mentioned above with JUSTIFIED RIGHT i did an inspect to make sure that i remove the leading spaces

code:
INSPECT WS-PERCENT REPLACING LEADING SPACES BY ZEROES
DISPLAY "WS-PERCENT" WS-PERCENT
IF WS-PERCENT IS NUMERIC
Do some statements
else
set Error swtich to true
END-IF

After the inspect it displayed
DISPLAY "WS-PERCENT" 0099.5

but the IF WS-PERCENT IS NUMERIC check is failing.Can someone correct me what is it that i am doing wrong here?? My ultimate aim is to make sure that the percentage value has valid numeric ,any other ideas are welcome
_________________
Bala V


COBOL Programming :: RE: Validate if a Value from the file is numeric

$
0
0
Author: Robert Sample
Subject: Reply to: Validate if a Value from the file is numeric
Posted: Tue Jun 20, 2017 12:39 am (GMT 5.5)

From the Enterprise COBOL Language Reference manual, page 210 (V6.1):
Quote:
For all numeric fields, the PICTURE character-string can contain only the symbols 9, P, S, and V.
Decimal points are not considered numeric characters, although signs are. You can check each character to be what you want or you can try using FUNCTION NUMVAL to convert the data to a numeric variable (which may cause problems if you have true non-numeric data in the variable).
_________________
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

CA Products :: RE: Easytrive Redefine

$
0
0
Author: Benchwarmer
Posted: Tue Jun 20, 2017 12:55 am (GMT 5.5)

Your post does not provide enough information for others to help. Provide full code.

You may be bypassing the first record.
_________________
Thanks,
Kratos

CLIST & REXX :: REXX to view the PGM or PROC

$
0
0
Author: jackzhang75
Subject: REXX to view the PGM or PROC
Posted: Tue Jun 20, 2017 1:20 am (GMT 5.5)

Hi Experts,

I am searching for the REXX macro or any ISPF function in REXX to open the PGM or PROC in JCL. Just like you can use "ISPEXEC BROWSE DATASET(" || DsNamQ || ")" to browse the data set in REXX so any similar thing or macro that works for PGM= or PROC= ?

Thanks

CLIST & REXX :: RE: REXX to view the PGM or PROC

$
0
0
Author: enrico-sorichetti
Subject: Reply to: REXX to view the PGM or PROC
Posted: Tue Jun 20, 2017 1:37 am (GMT 5.5)

and what do You expect to see/understand when browsing a load module?

while it is easy to extract whatever token You might want using an edit macro

finding the target of an exec it will not be easy ...
a program might reside in a strplib/joblib dsname or anywhere in the linklist concatenation

and a proc will be somewhere in the proclib concatention og the JES procedure
_________________
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

CLIST & REXX :: RE: REXX to view the PGM or PROC

$
0
0
Author: David Robinson
Posted: Tue Jun 20, 2017 1:41 am (GMT 5.5)

Shouldn't be too difficult. You still use the ISPEXEC BROWSE function, you just have to supply the name of your procedure libraries or source libraries, as appropriate.
Viewing all 8500 articles
Browse latest View live