VS Code Copybook resolvement - DATA SET ... NOT FOUND messages in the STC

Hi,

When I edit a program with copybook download they are nicely downloaded to the workstation. I noticed that SYSL00XM is correctly called, however for every copybook that the workbench wants to download I'm getting messages 'DATA SET ... NOT FOUND' in the STC :

When a build is triggered, these messages do not appear. So my question is :

- How does the retrieval works

- If SYSL00XM is called and the SYSLIB is adapted, why is the STC still making references to datasets that were not in the adapted syslib

Thank you

Please provide a copy of your SYSL00XM exit code and more details of what you are doing. Please include the steps. 

Please provide a copy of your SYSL00XM exit code and more details of what you are doing. Please include the steps. 

Hi David,
I got it figured out. You must create a workspace and at the root of the workspace a correct zapp.yaml file must be created

When working with the workspace and the yaml file correctly defined, teh copybooks are nicely resolved in the editor

BRs
Johan

I have discussed this with IBM z/Open Editor Team and they are saying that they have assumed the existence of a Workspace and that the zapp.yaml is present in that workspace.   The alternative is to simply open a folder that contains the zapp.yaml file and VSCode will remember it for future use.

The ZMF Explorer has never mandated that a Workspace exists.

IBM have also indicated that they may change this based on feedback.

Hi David,
Thank you for the feedback. My personal comments

- When using the ZMF Explorer, the source component is stored within the package folder as  folder and within that folder the programs source and its included copybooks

- This means that every program must be defined as a workspace, as every program has its own folder and how own version of copybooks

- I would rather like to see that the program resides in the package folder and all related copybooks. This makes more sense, so that when I edit another program that it uses the same folder. When a package is edited and compiled in hangman, every program uses the same version of copybooks. When editing a component in ZMF Explorer this should read the same way

- In ZMF your package is the work environment, so why not use the same concept for the ZMF Explorer

When doing so, when a program is edited, the app.yaml file could be generated automatically by ZMF Explorer (set by an optional flag in the JSON ZMFSettings)

What is your opinion on this?

Best regards

Johan

I have to admit to being a little confused as to what you are saying here. I do not know what you are referring to with the comment 'every program must be defined as a workspace'.  'Workspace' is a VSCode term.

When a component is clicked, you are prompted to also optionally bring down its copybooks.
As the component and its copybooks are all retrieved, they are saved in a folder that you define in Settings:


Using this example, the component is saved in a subfolder of
d:/myFolder/<profile>packages<packagename<componentname> 

When a local component is subsequently edited and checked back into the package, the local subfolder is deleted in its entirety thereby removing the local component and its copybooks. 

Perhaps there is a misunderstanding. Please note that the copybooks that are brought down to the local desktop machine - are not editable. They are only brought down for the sole purpose of allow VSCode Intellisense to resolve field names in the main component. Once the component has been edited and checked back in the local component and its copybooks are deleted.

zapp.yaml will not be created by the ZMF Explorer as a user can choose to use any language editor of choice and is not tied to using IBM z/Open Editor. ZMF Explorer does not know what language editor is being used. The zapp,yaml  is an IBM z/Open Editor specific requirement and is created once only. As I mentioned previously, IBM are considering allows the zapp.yaml to be placed in the <homedir> at some point.

All understood and documented. You are fully right and in the meantime we are looking into other editors for PL1