First lets give an overview of the system situation here (all SAG products are on the latest version):
- Natural environment on mainframe
- NaturalONE runs on Windows PCs
- SVN is on a Linux machine
Inside of NaturalONE if you create a new Natural object, it is possible to have a different file name as the object name is.
The file name can have more than the 8 characters length limit and only must comply to the workspace filesystem rules (e.g. in NTFS you can include blanks and can not include &, etc.). The file name could even have no name of the Natural object in it!
Inside of the header section of the Natural Object the real object name is being kept inside the variable NatName.
Also NaturalONE does support library folders, so to get a more organized view onto your source modules. Please see in the N1 documentation for this.
Instead of directly connecting to the Natural environment on mainframe via the NDV, we are using SVN to store the sources. The Natural environment on mainframe is only being used to manually save and stow Natural objects during the development phase for testing only.
Now then, as soon the local development is done, you move the sources up to the next stage.
In this case, the sources are included as EXTERNAL source from the SVN into the PAC with status development.
AND here we arrived at my questions to you:
- Anyone knows, if the REQUEST DOCUMENT of PAC has a URL length limit and what it is?
- Also will PAC recognize the header of the Natural object and use the variable NatName to receive the real Natural Object Name instead of the filename (which is not suitable for mainframe)?
The documentation on REQUEST DOCUMENT only states that URL is of type A DYNAMIC. Those can get theoretically very large, and I am not sure, PAC can really work with the full specified length of 1GB. Well for URLs there seems to be a limit of 2000 characters. Is PAC going to work with that?
here the relevant copy from the documentation:
• Anyone knows, if the REQUEST DOCUMENT of PAC has a URL length limit and what it is?
Documentation: Predict Application Control/PAC User’s Guide/Using the Migration List Editor:
For events with From Status EXTERNAL the migration list editor provides a specific additional function, when using the SEL command. When adding or modifying a URL with the editor, you can expand each line in the editor with the PF5 key. You are then able to add or edit long URL strings (up to 250 characters) more easily. In addition, when you are in the expanded lines mode, you can scroll through the migration list back and forth using the PF7 and PF8 keys.
• Also will PAC recognize the header of the Natural object and use the variable NatName to receive the real Natural Object Name instead of the filename (which is not suitable for mainframe)?
Documentation: Predict Application Control/Using External Version Control with PAC:
The Natural member name, the programming mode, the save date, the user and the code page information will be extracted from the source text. This information is either inserted into the source text by the Local Versioning plug-in or by Natural for Eclipse. If that information does not exist, default values will be used. The member type of the source file can only be derived from its extension. Those URLs that do not allow to determine the member type will be rejected.
Than you very much, Hardy, for the provided answers.
Also found in the documentation of the APIs, that this limit of 250 characters is also valid for them.
Well 250 is not much, if you have a repository URL, which should also include long file names and library folders.
In our primitive “simulate the mainframe” solution (only 8 chars, no folders), we are already using up 73 characters for the URL. Now think about organizing things properly with folders and meaningful names…
Maybe it is possible to check somewhere in the process of a commit, if the URL would be too long for being used by PAC.
Anyone got an idea how to accomplish this?
What about using an URL shortener for this ?
You can implement your own, local one and don’t have to use any of the public ones.
That is a fantastic idea to circumvent the problem!
Gonna go for this, thanks!