View previous topic :: View next topic
|
Author |
Message |
prashant_mq
New User
Joined: 29 Aug 2006 Posts: 24
|
|
|
|
Hi,
Can I declare s9(19) in cobol.
What is the maximum numeric digits allowed.
Whats the alternative to use s9(19).
Thanks |
|
Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007 Posts: 1512 Location: Virginia, USA
|
|
|
|
You need to check the manuals for your version of COBOL
For Enterprise COBOL
Quote: |
For binary items, the number of digit positions must range from 1 through 18 inclusive. For packed decimal and zoned decimal items the number of digit positions must range from 1 through 18, inclusive, when the ARITH(COMPAT) compiler option is in effect, or from 1 through 31, inclusive, when the ARITH(EXTEND) compiler option is in effect. |
|
|
Back to top |
|
|
prashant_mq
New User
Joined: 29 Aug 2006 Posts: 24
|
|
|
|
How do you declare in the JCL? |
|
Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007 Posts: 1512 Location: Virginia, USA
|
|
|
|
You don't declare COBOL Pic's in JCL! |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
Whats the alternative to use s9(19). |
Please explain the content of (or how you will use) a 19 digit number.
Show a few actual values and how they might "decompose".
For example a number like 70355523236784 could be a phone number consisting of the area code (703), the access/exchange code(555), the specific phone (2323) and the "extension" (6784). Is your number a collection of components? |
|
Back to top |
|
|
prashant_mq
New User
Joined: 29 Aug 2006 Posts: 24
|
|
|
|
Craq Giegerich wrote: |
You don't declare COBOL Pic's in JCL! |
No, I mean how do you declare the ARITH(EXTEND) in JCL? |
|
Back to top |
|
|
prashant_mq
New User
Joined: 29 Aug 2006 Posts: 24
|
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
ARITH(EXTEND) is one of the parms that may be supplied to the compiler. It is usually specified as an override in the execute jcl.
When your compile is submitted, there are most likely parameters supplied in the compile PARM. You would need to add ARITH to those parms.
I'd suggest you talk with whoever supports your standard compiler processes and explain the requirement and they should be able to show you how to do this on your system. |
|
Back to top |
|
|
stodolas
Active Member
Joined: 13 Jun 2007 Posts: 632 Location: Wisconsin
|
|
|
|
We put it as the very first line in the COBOL source if we need it. Before any IDENTIFICATION or anything else it acts as a precompiler directive. |
|
Back to top |
|
|
prashant_mq
New User
Joined: 29 Aug 2006 Posts: 24
|
|
|
|
dick scherrer wrote: |
Hello,
ARITH(EXTEND) is one of the parms that may be supplied to the compiler. It is usually specified as an override in the execute jcl.
When your compile is submitted, there are most likely parameters supplied in the compile PARM. You would need to add ARITH to those parms.
I'd suggest you talk with whoever supports your standard compiler processes and explain the requirement and they should be able to show you how to do this on your system. |
Hi, Thanks for your help, however I have still getting the "more than 18 bytes " error after I have added the ARITH(EXTEND). Could it be compiler version problem as I'm using Enterprise COBOL 3.4.1 ? |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
Could it be compiler version problem as I'm using Enterprise COBOL 3.4.1 ? |
That version is current.
Please post your jcl/source where you specified arith(extend) as well as the part of the output that shows the compiler optons in effect for your compilation. |
|
Back to top |
|
|
stodolas
Active Member
Joined: 13 Jun 2007 Posts: 632 Location: Wisconsin
|
|
|
|
Here is how we do it. It goes as the first line in the COBOL source.
Code: |
PROCESS ARITH(EXTEND)
IDENTIFICATION DIVISION.
PROGRAM-ID. MYPROG.
AUTHOR. S STODOLA.
INSTALLATION. MY COMPANY.
DATE-WRITTEN. SEPTEMBER 30, 2005.
|
|
|
Back to top |
|
|
prashant_mq
New User
Joined: 29 Aug 2006 Posts: 24
|
|
|
|
dick scherrer wrote: |
Hello,
Quote: |
Could it be compiler version problem as I'm using Enterprise COBOL 3.4.1 ? |
That version is current.
Please post your jcl/source where you specified arith(extend) as well as the part of the output that shows the compiler optons in effect for your compilation. |
Compilation error: IGYDS1505-S: More than 18 digit positions were specified in a "PICTURE" of "S9(18)" was assumed.
The JCL is, you can look at the attachment as well:
//SETPP JOB 30000030000CN,INGM001,CLASS=A,MSGCLASS=Q,
// NOTIFY=INGM001,MSGLEVEL=(0,0),REGION=6M
//********************************************************************
//* *
//* LICENSED MATERIALS - PROPERTY OF IBM *
//* *
//* 5645-001 *
//* (C) COPYRIGHT IBM CORP. 1988, 1997 ALL RIGHTS RESERVED *
//* *
//* US GOVERNMENT USERS RESTRICTED RIGHTS - USE, *
//* DUPLICATION OR DISCLOSURE RESTRICTED BY GSA ADP *
//* SCHEDULE CONTRACT WITH IBM CORP *
//* *
//EDCCPL EXEC IGYWCL,PARM.COBOL='OBJECT,LIB,APOST,LIST',
// PARM.LKED='AMODE=24,RMODE=24'
//COBOL.SYSLIB DD DSN=SYS1.WMQ700.SCSQCOBC,DISP=SHR
//SYSIN DD DSN=INGM001.MQ70.CBLS(SETPROP),DISP=SHR
//LKED.CSQSTUB DD DSN=SYS1.WMQ700.SCSQLOAD,DISP=SHR
//LKED.BSQSTUB DD DSN=INGM001.COBOL.LOAD,DISP=SHR
//LKED.SYSIN DD *
INCLUDE CSQSTUB(CSQBSTUB)
/*
//LKED.SYSLMOD DD DSN=INGM001.COBOL.LOAD(SETPPEXE),DISP=SHR
|
|
Back to top |
|
|
prashant_mq
New User
Joined: 29 Aug 2006 Posts: 24
|
|
|
|
I have tried to put the ARITH(EXTEND) on the PARM.COBOL= in JCL and also PROCESS ARITH(EXTEND) or CBL ARITH(EXTEND) before the IDENTIFICATION DIVISION, however it is still failed. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
You have posted nothing that shows where you used the extend
Have you tried the method Steve posted? In the code or in the jcl will work so you should check with your organization on which method is proper for your system. Either should get you thru an initial test.
So far, we've seen nothing that would tell the compiler that large numbers were valid. |
|
Back to top |
|
|
prashant_mq
New User
Joined: 29 Aug 2006 Posts: 24
|
|
|
|
I have tried with this:
//EDCCPL EXEC IGYWCL,PARM.COBOL='OBJECT,LIB,APOST,LIST,
// ARITH(EXTEND)',
as well as this:
CBL ARITH(EXTEND)
IDENTIFICATION DIVISION.
but still no success. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
Ok so now we have zillions of confirmation that it does not work,
it will keep on not working until You post an excerpt of the sysout
showing the active options for Your compile step.
But I would say that this is more an issue for Your support rather than a forum
COBOL is not my friend, but thinking in parallel with PL/I
when the defaults options are being setup at installation time
the options are divided in two section
the overridable ones ( the ones that can be changed by parm or process )
the not-overridable ( the ones that cannot be changed )
check with Your support if this is the case
giving as evidence what has been requested a few times,
and You still did not provide |
|
Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007 Posts: 1512 Location: Virginia, USA
|
|
|
|
The compiler is installed and set up with default compiler options. While installing the compiler, the system programmers for a site can fix compiler option settings to, for example, ensure better performance or maintain certain standards. You cannot override any compiler options that your site has set as fixed. For options that are not fixed, you can override the default settings by specifying compiler options in either of these ways:
The first page of your compile listing should look something like this
Code: |
PP 5655-G53 IBM Enterprise COBOL for z/OS 3.4.1 Invocation parameters:
AR(E),MAP,OPT,NOSEQ,XREF,LIST,SSR,CICS,TRUNC(BIN),,NOADV,LIB,RENT,NODYNAM
PROCESS (CBL) Statements:
CBL NORW LINECOUNT(57)
CBL SQL("APOSTSQL STDSQL(NO)") NORW LINECOUNT(57)
Compiler options in effect:
NOADATA
NOADV
|
You can look at this and see if 'ARITH(EXTEND)' is being used or not. In this listing AR(E) is being passed as a compile time option for ARITH(EXTEND). |
|
Back to top |
|
|
prashant_mq
New User
Joined: 29 Aug 2006 Posts: 24
|
|
|
|
Craq Giegerich wrote: |
The compiler is installed and set up with default compiler options. While installing the compiler, the system programmers for a site can fix compiler option settings to, for example, ensure better performance or maintain certain standards. You cannot override any compiler options that your site has set as fixed. For options that are not fixed, you can override the default settings by specifying compiler options in either of these ways:
The first page of your compile listing should look something like this
Code: |
PP 5655-G53 IBM Enterprise COBOL for z/OS 3.4.1 Invocation parameters:
AR(E),MAP,OPT,NOSEQ,XREF,LIST,SSR,CICS,TRUNC(BIN),,NOADV,LIB,RENT,NODYNAM
PROCESS (CBL) Statements:
CBL NORW LINECOUNT(57)
CBL SQL("APOSTSQL STDSQL(NO)") NORW LINECOUNT(57)
Compiler options in effect:
NOADATA
NOADV
|
You can look at this and see if 'ARITH(EXTEND)' is being used or not. In this listing AR(E) is being passed as a compile time option for ARITH(EXTEND). |
Attached herewith the listings, the listing1 (top) is showing ARITH(EXTEND) is in effect but on the listing2 (bottom) is giving error. |
|
Back to top |
|
|
prashant_mq
New User
Joined: 29 Aug 2006 Posts: 24
|
|
|
|
Hi Craq, I'm getting the AR(E) on the listing, could it be the option cannot be overridable? |
|
Back to top |
|
|
prashant_mq
New User
Joined: 29 Aug 2006 Posts: 24
|
|
|
|
prashant_mq wrote: |
Hi Craq, I'm getting the AR(E) on the listing, could it be the option cannot be overridable? |
Sorry I mean I'm NOT getting the AR(E) |
|
Back to top |
|
|
stodolas
Active Member
Joined: 13 Jun 2007 Posts: 632 Location: Wisconsin
|
|
|
|
Odd that it shows that the ARITH(EXTEND) option is in effect already. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
just a hint... long binary up to pic s9(18) are stored as dublewords ( 8 bytes )
I could not find anything on binry with more than 18 digits
number theory
a pic s9(19) will allow a number like 9.999.999.999.999.999.999
and it will definitely not fit in 8 bytes signed
here is a table of 2 powers
Code: |
/09876543210987654321
1/ 2
2/ 4
3/ 8
4/ 16
5/ 32
6/ 64
7/ 128
8/ 256
9/ 512
10/ 1024
11/ 2048
12/ 4096
13/ 8192
14/ 16384
15/ 32768
16/ 65536
17/ 131072
18/ 262144
19/ 524288
20/ 1048576
21/ 2097152
22/ 4194304
23/ 8388608
24/ 16777216
25/ 33554432
26/ 67108864
27/ 134217728
28/ 268435456
29/ 536870912
30/ 1073741824
31/ 2147483648
32/ 4294967296
33/ 8589934592
34/ 17179869184
35/ 34359738368
36/ 68719476736
37/ 137438953472
38/ 274877906944
39/ 549755813888
40/ 1099511627776
41/ 2199023255552
42/ 4398046511104
43/ 8796093022208
44/ 17592186044416
45/ 35184372088832
46/ 70368744177664
47/ 140737488355328
48/ 281474976710656
49/ 562949953421312
50/ 1125899906842624
51/ 2251799813685248
52/ 4503599627370496
53/ 9007199254740992
54/ 18014398509481984
55/ 36028797018963968
56/ 72057594037927936
57/ 144115188075855872
58/ 288230376151711744
59/ 576460752303423488
60/ 1152921504606846976
61/ 2305843009213693952
62/ 4611686018427387904
63/ 9223372036854775808
64/18446744073709551616
|
also by looking a bit around seems like pic s9(xx) with xx greater than 18
might work only for not binary
it would be worth trying with an usigned representation
pic 9(19) binary, since in this case it is a binary handle the sign would be irrelevant |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10873 Location: italy
|
|
|
|
just to sum up things, the answer to the O/P ( original post) seems to be,
YES, but not for BINARY
as I said before since the sign is irrelevant I would try with "PIC 9(19)"
but, it would have been nicer on Your side to say from the beginning that
You were also specifying BINARY without us having to click around |
|
Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007 Posts: 1512 Location: Virginia, USA
|
|
|
|
enrico-sorichetti wrote: |
just to sum up things, the answer to the O/P ( original post) seems to be,
YES, but not for BINARY
as I said before since the sign is irrelevant I would try with "PIC 9(19)"
but, it would have been nicer on Your side to say from the beginning that
You were also specifying BINARY without us having to click around |
I told him that earlier
Quote: |
For Enterprise COBOL
For binary items, the number of digit positions must range from 1 through 18 inclusive. For packed decimal and zoned decimal items the number of digit positions must range from 1 through 18, inclusive, when the ARITH(COMPAT) compiler option is in effect, or from 1 through 31, inclusive, when the ARITH(EXTEND) compiler option is in effect.
|
|
|
Back to top |
|
|
|