Asktime should set a properly formatted COMP-3 in EIBTIME

The CICS and Cobol Development teams have had detailed discussions concerning use of NUMPROC(PFD) and have come to agreement that this RFE is declined.

With COBOL having its unique behaviour and other languages not apparently having known problems, we decided at a CICS Architecture Board meeting to reject the idea of doing anything for EIBTIME/EIBDATE and their behaviour for NUMCHECK and NUMPROC. Even an opt-in to a changed behaviour (and we considered opt-in variants for both source changes and just a runtime change) to be sufficiently error-prone and/or poorly adopted to justify compared to living with the current behaviour.

The CICS Knowledge Center has been updated in this topic https://www.ibm.com/support/knowledgecenter/SSGMCP_5.6.0/applications/developing/cobol/dfhp3_cobol_prog.html where it lists compiler options to state:
"NUMPROC(PFD) must not be used because values used in assignments to COBOL variables (including values assigned by CICS) may not meet the stricter numeric test. Such contraventions, when NUMCHECK(PAC) is also used, will result in a potentially high rate of IGZ0279W messages to be issued, impacting performance."


In more detail, the RFE is declined because:
a) CICS cannot transparently support this due to the widespread use of both fields and the use of the EXEC CICS ASKTIME command. It is not realistic for CICS to change an underlying data format without a review from an application code perspective.

b) Cobol has support to 'do the right thing' when moving time and date fields into user fields and adjusting to match the attributes of the target field. The problem comes with other languages which will just move four bytes and have no knowledge of the sign.

c) Whilst an API option change means a user has to opt in and consider the consequences, later changes or additions to the application suite need to adhere to the same new standard regardless of programming language

d) A user needs to be aware that all code manipulating the fields would need to be changed, else an old unchanged part of the application would use the existing ASKTIME command resulting in EIBTIME reverting back to the old unsigned format. This will cause PFD problems again for Cobol applications using the new standard.

e) Issuing the COBOL IGZ0279W message the first time either EIBTIME or EIBDATE is referenced by any line of code in a module compiled with PFD can, and has, lead to severe performance problems being experienced. Every CICS transaction is a separate LE enclave and each message comprises of three lines of data that is written to CICS Extra partition transient data queue CESE . For example a basic program compiled with this option produces 3 instances of IGZ0279W and a transaction rate of 1000 txns/second results in 3000 lines of data being written to CESE - the extra i/o involved has been found to severely impact the performance of a CICS region. It is for this reason that CICS documents NUMPROC(PFD) as an unsupported compile option.

Rune, the original http://www.ibm.com/developerworks/rfe/execute?use_case=viewChangeRequest&CR_ID=138489 which was declined, implied you wanted a change in ASKTIME behaviour which was unacceptable from a compatibility point of view. However if a new command is acceptable, or a new option on ASKTIME which you have to opt into, both of which imply existing applications will have to be changed to explot this, then yes we can look into providing this.

This is a candidate for a future release.

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
Component - Other
Operating system - IBM z/OS
Source - None

For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - Programming Languages
Product - COBOL Compilers
Component - Miscellaneous
Operating system - IBM z/OS
Source - None

Hi,

Yes, that would be acceptable.
The solution I had been thinking about, was post processing by COBOL, to set the correct bits, when using the affected options.

Regards,
Rune

Hi,

From a COBOL perspective, there isn't anything that can be done.

However, we reached out the CICS team and got a response.

A new variant of ASKTIME with the suggested changes (eg: ASKTIME2) is possible (either a new command or an option on the existing command, but would default to 'off' on the new option).

So that implies an application change would be needed because the default status quo of the current ASKTIME would not change.

May we know if such an application change is acceptable?
If so, then this RFE will need to be transferred to the CICS team.

Thanks.

This RFE is still being investigated.