Hello, 
Encountering an issue with a sequential data set being created differently depending on the LLQ part of the dataset name.  A program creates KC03G4C.FINAL2.DATA.S with LRECL=36, and there appears to be something past column 36 when you view the data set with Developer for z/OS version 14.2.1.1.

Rename the file to KC03G4C.FINAL2.DATA.SSAVE, and the view of the data set looks like there is nothing past column 36 when you view the data set with Developer for z/OS version 14.2.1.1.

In both cases, the JCL and program have the LRECL=36.

It also seems that when the LLQ=S that the next program that tries to input the data set has a problem.
When the LLQ=SSAVE the next program works fine. 

From some testing, it seems this only happens for LLQ=S, and not for any other single character LLQ, or any other combination of characters that is a valid LLQ.

Does the LLQ=S have some special meaning to the environment, or IDz that would cause this?

Regards,

Greg
 

Attachment(s)

Screenshots of views.zip   307 KB 1 version

Hi Greg,
Thanks for all the details they were very helpful for us to understand your issue.   It seems that the editor you are using to open the sequential datasets is the System z LPEX Editor and that editor is using the S in the LLQ as the file extension and treating it like the content is Assembler.   One thing you could do is open the z/OS File System Mapping view and Add a Data Set Mapping entry with  **DATASAVE** as the Mapping Criteria and tdat as the Workstation File Extension.  Doing this should treat all datasets with "DATASAVE" in the name as a file with a .tdat file extension.  This will cause the System z LPEX Editor to behave the same for LLQ=S as LLQ=SSAVE.   It will also allow you to Open With > System z Data Editor for your sequential datasets with the "DATASAVE" naming convention. 

However, all of this should not have any impact on the behavior of a program running in batch that uses these datasets.   That part of your question/comment is puzzling.

I hope this helps.