Please let me know if we can have a PD field converted to Numeric data using

SYNCSORT.

For Example: I have a file1 with the ff data

AA ---- PD field

I want to have an output file as

AA ---- Numeric data (Converted value of the PD field).

Please find below the statement:

SORT FIELDS=COPY
OUTREC FIELDS=(1,2,3,3,PD,TO=ZD,LENGTH=5)

Below are the run details:

Input =>
Code:
aa..�
88135
1124F

Syntax =>
Code:
SORT FIELDS=COPY
OUTREC FIELDS=(1,2,3,3,PD,TO=ZD,LEN=5)

Output =>
Code:
aa12345

---

You can use the below control card of SORT

Code:

//SYSIN DD *
SORT FIELDS=COPY
OUTREC BUILD=(1,2,3,8,PD,EDIT=(IIIIIIIIIIIIIII),80:X)
/*

----------

cobol - numval and numval-c

The NUMVAL and NUMVAL-C functions convert character strings to numbers.

Use these functions to convert alphanumeric data items that contain free
format character representation numbers to numeric form and process them
numerically. For example:

01 R Pic x(20) Value "- 1234.5678".

01 S Pic x(20) Value " $12,345.67CR".
01 Total Usage is Comp-1.
.
.
Compute Total = Function Numval(R) + Function Numval-C(S)
 The difference between NUMVAL and NUMVAL-C is that NUMVAL-C is used when
the argument includes a currency symbol and/or comma, as shown in the
example. You can also place an algebraic sign in front or in the rear,
and it will be processed. The arguments must not exceed 18 digits (not
including the editing symbols).

---------

I happened to be researching this, and came across this topic.

As indicated earlier in the topic, an alphanumeric literal is limited to 160 bytes.

This is in the 1985 ANSI Standard,

When specifying a VALUE with a literal... you run into the limit not of the VALUE
clause, but of the alphanumeric literal. It is the size of the literal itself that
is the problem. With a figurative constant, or ALL as was shown, there is no
problem with the size.

160 bytes is a limit of the Standard, not of the compiler. In the '68 Standard, it
was a compiler-implementation limit. In the '74 Standard, it was specified, as 120,
for a "non-numeric literal". In '85 extended to 160 for an alphanumeric literal
(change of name). In 2014, it is 8191.

The Compiler Limits is a little confusing:

Total 01 + 77 (data items) No limit

88 condition-names . . . No limit
VALUE literal . . . No limit

I think what this means is there is no compiler limit to the number of VALUE
clauses. There is of course another compiler limit which will affect that anyway,
which is 999,999 lines of source.

Splitting the field into smaller items seems a better way to get a long literal.

Code:
01 some-name.
05 FILLER PIC X(60) VALUE
"12345678901234567890123456789012345678901234567890AAAAAAAAA".
05 FILLER PIC X(60) VALUE
"12345678901234567890123456789012345678901234567890AAAAAAAAAA".
etc

for numeric it is 9 (18) is limit

--------