Enhancement to DFHLS2WS

This requirement has been re-evaluated. Looking at current plans, it is not likely that this would be implemented in the twelve months, so correspondingly this requirement is being rejected. You have an opportunity to resubmit in twelve months time if you wish it to be considered then.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

Here's an example of an input/output structure pair using PIC fields. One of my developers wanted to use these. Does this help?

DCL
1 RRTCCTL_IN DEF DA$INMSG,
/* RRTCCTL FIELDS */
2 ROUTINE_NAME CHAR(7),
2 HIDUR PIC'999',
/* RRTCPRE FIELDS */
2 RRSERIES PIC'99',
2 RRPLAN PIC'999',
2 RRORIGTERMISSAGE PIC'999',
2 RRSEX CHAR(1),
2 RRCURPOLDUR PIC'999',
2 RRORIGCLASSEXCODE CHAR(2),
2 RRORIGYRISSUE PIC'9999',
2 ORIGRATE_SERIES_CDE CHAR(3),
2 RRSMOKER_CODE CHAR(1),
2 RRSEXNEUTRALCODE CHAR(1),
/* RRTCPST FIELDS */
2 RRCONVDUR PIC'999',
2 RRCLASSEXCODE CHAR(2),
2 RRYEAR_CONV PIC'9999',
2 RRVALCODE CHAR(1),
2 RRTC_RESERVE_CODE CHAR(1);

DCL
1 RRTCCTL_OUT DEF OUTPUT_STRING,
2 VALUES_ARRAY(42),
3 RRVALNET PIC'-999V.99',
3 RRRESINI PIC'-9999V.99',
3 RRRESTER PIC'-9999V.99',
3 RRRESMEAN PIC'-9999V.99',
3 INTEREST_RATE PIC'-9V.9999',
2 STATUS CHAR(5),
2 ERROR_MESSAGE CHAR(50);

Thanks for the update Bob. This is a candidate for a future release

For our shop we wouldn't be using the PIC cause for any input fields, just for output. In most cases the PLI program would be formatting the data into the PIC fields with the expectation that the data mapper would treat the fields are character fields, i.e. the data would just get moved, not re-formatted. I'm gussing that whatever you provide would work for us.

COBOL and PL/I both have the concept of PICTURE clauses, but the languages are different in what they support. The PICTURE clause in PL/I is more sophisticated than that of COBOL. DFHLS2WS's support for PICTURE in COBOL is reasonably good, if imperfect. However, we don't support PICTURE at all in PL/I.

     A candidate item for consideration for a future release could be to enable a subset of PICTURE clauses for PL/I. That could be done relatively easily, but the vast bulk of valid PL/I picture clauses would remain unsupported. Would this be acceptable ?

No further information yet received from the customer

COBOL and PL/I both have the concept of PICTURE clauses, but the languages are different in what they support. The PICTURE clause in PL/I is more sophisticated than that of COBOL. DFHLS2WS's support for PICTURE in COBOL is reasonably good, if imperfect. However, we don't support PICTURE at all in PL/I.

     A candidate item for consideration for a future release could be to enable a subset of PICTURE clauses for PL/I. That could be done relatively easily, but the vast bulk of valid PL/I picture clauses would remain unsupported. Would this be acceptable ?