Local syntax check of a remote file from an editor

When you request a local syntax check for a remote COBOL or PL/I file, the syntax check operation searches the remote system for all dependencies (such as copybooks and include files) and caches these files in a temporary location in your workspace. The list of files is also stored as a property of the remote file. This search and temporary caching enables a syntax check operation to complete without requiring you to add the dependent files to your MVS subproject.

Before you begin

Limitations:
  • Local syntax check is deprecated. This action is available only on Windows.
  • Local syntax checking does not support shift-out-shift-in (SOSI) sources. The importer that is used to do the local syntax check supports only UTF-8 encoding. Translating CP-930 and other SOSI sources into UTF-8 alters the column locations for some characters, and this alteration results in unexpected errors.

Before you check syntax locally, you might need to set local build options. You must do this action only once and only if you want to override the default values.

This procedure outlines the default behavior for local syntax check. You can override this default behavior and request that the syntax check operation look only in your subproject for dependent files. To override this default behavior, select the Syntax Check option in the Preferences window. For more information, see the related links.

Restriction: A local syntax check of a remote file that contains copy members might use stale copy members from the cache if the copy member was moved to a different location in the SYSLIB concatenation that is specified in the SYSLIB field of the property group. This situation can occur if you have two identically named copy members in different locations of the SYSLIB concatenation, perform a syntax check, and then delete the identically named copy member that is highest in the concatenation. To work around this problem, do these steps:
  1. In the Preferences window, navigate to Remote Systems > File Cache, and then press Clear Cached Files.
  2. Right click in the Remote Error List, and remove all error messages. This step prevents any error messages from existing copy files from being displayed.
  3. Perform the local syntax check and refresh dependencies to make sure that the copy files are refreshed in the cache location.

Procedure

To do a local syntax check of a remote file from an editor, follow these steps:

  1. Open the member in the z Systems® LPEX Editor, COBOL Editor, or PL/I Editor.
  2. In the content area of the editor, right-click and select Syntax Check > Local (or press Ctrl+Alt+L) or Save and Syntax Check > Local if the file was changed.
    The Check Dependencies window opens, prompting you to refresh dependencies for the remote file.
  3. Optional: If you have reason to believe that the dependencies changed since the last syntax check, click Refresh dependencies and then perform a syntax check. Otherwise, click Syntax check only.
    To review the list of dependencies before proceeding, click Dependent files. The window expands to show the list of dependent files and the date and time of the last refresh.
    Note: The Dependent files button is present only if you previously requested a refresh dependencies for the file.
  4. Click OK.
    The local compiler is started to perform the syntax check.
    Note: Unless you select Save and Syntax Check > Local, your file is not automatically saved before initiating the syntax check.
    When the syntax check is completed, any errors are displayed in the Remote Errors List. If there are no errors, control is returned to you and you can continue working.

Results

The following error messages represent some common problems with local syntax check of remote files. These messages might appear in the Refresh Dependencies Problems window. Click Details to display the specific error message.
  • JES subsystem is not connected. Connect to the subsystem and retry the operation. This message might appear if the JES subsystem is not connected.
  • The submitted job has ended with a JCL error. Check the build properties and retry the operation. This message might appear if, for example, you specified a partitioned data set in the SYSLIB that does not exist.