Issue with *DTAARA QSYS/QCPTOIMPF

[smartrocks]

The current version of Code for IBM i does not work correctly with the V5R2 version of CPYTOIMPF. In particular, it will not display source code for a source member in this case. Since it is infeasible to change all the applications on our system to no longer need the V5R2 version CPYTOIMPF, I am looking for a workaround.

If the *DATAARA existed in QTEMP with value NO in the Code for IBM i extension, would that solve the problem? Is there a way to have this command executed in that job CRTDTAARA DTAARA(QTEMP/QCPTOIMPF) TYPE(*CHAR) LEN(6) VALUE('NO')?

Background: My employer has many old applications requiring use of the V5R2 version of CPYTOIMPF. With V5R3 some IBM customers complained of a problematic change in CPYTOIMPF behavior. The IBM fix was to enable V5R3+ customers to resume use the V5R2 behavior by creating *DTAARA QSYS/QCPTOIMPF with value 'CPV5R2'. A job running on a system configured this way can use the current version of CPYTOIMPF by creating the same *DTAARA in QTEMP with value "NO".

Thanks!

[smartrocks]

Edit: If the *DATAARA existed in QTEMP with value NO in the server job that supports the Code for IBM i session, would that solve the problem? Is there a way to have this command executed in that job --> CRTDTAARA DTAARA(QTEMP/QCPTOIMPF) TYPE(*CHAR) LEN(6) VALUE('NO')?

[SJLennon]

FWIW: I am not one of the maintainers, who may have better information.

The Requirements say "IBM i 7.3 TR 8 minimum".

I doubt if putting a copy of the QCPTOIMPF dtaara in QTEMP would work, since the QSYS is higher in the library list.

There is an IBM reference to a QTEMP/ QCPNOBLANK data area, but I doubt if that could be made to work either unless you are willing to change your existing code.

[smartrocks]

I'm at IBM i 7.5 and have all PTF's. Putting a copy of the QCPTOIMPF dtaara in QTEMP does work. I use it all the time. It's a documented work around provided by IBM (reference: https://www.ibm.com/support/pages/cpyfrmimpf-and-cpytoimpf-data-areas) . It's just that it needs to be part of the IBM i job that supports VS Code sessions. Otherwise the source code will not display in VS Code. At some point I'll try creating my own command in VS Code to right click on QTEMP in my library list to create the data area there and hope for the best.

[smartrocks]

This works because IBM modified the O/S to first check for these particular data areas in QTEMP before checking in QSYS.

[sebjulliand]

Unfortunatelly, for the time being, even the workaround won't work because the SSH connection between VS Code and IBM i is stateless. Every 5250 command is run using the system shell command which spawns a new job every time it runs. So creating anything in QTEMP is not an option here.

However, in the near future (version 3 of the extension, presumably), commands will be called through Mapepire, which is stateful. So running a custom action that will create that DTAARA in QTEMP in this context should work.

But for now, I don't see a good way to avoid your issue. Does enabling (or disabling) source dates support in the settings changes anything for you ? (since enabling this changes the way source members are retrieved, it may help...)

[bobcozzi]

I wonder if adding a pre-run list of CL commands to the Connection Profile would soft this? (Once on Mapepire). For example, a setting named "Connection-SETUP:" that contains a semi-colon delimited list of CL commands that are sent to the host once connected. If it is empty or doesn't exist, then nothing runs. Just an idea.