Question on default file extensions
Abe Kornelis
All,
I have been looking into RPI 1633 / Issue 204 - https://github.com/z390development/z390/issues/204
On Unix systems it is impossible to refer to a macro file if it
has no extension. On windows there is no distinction between [.]
and [], but on Unix the distinction is relevant. Please adjust
code to make sure on Unix systems a path ending in dot is
interpreted as meaning to find a file with or without the trailing
dot.
--> So the problem is that Unix differentiates between filenames ending in a period (myfile.) and having no period (myfile) whereas Windows treats these names as being equal. The way z390 applies a default extension makes it impossible on Unix/Linux to use macros that do not have an extension, not even a trailing period.
The primary example of this issue occurring is with the MVS3.8
maclib, which holds macros GETMAIN using just the MVS ember name.
To set up a path for including these macros z390 expects sysmac(+mypath/*.)
which works on Windows, but fails on *ix because of the period
included in the file name pattern, which does not match the actual
file name. using * instead of *. is no option, as that prompts
z390 to use the default extension of .mac - obviously *.mac will
not be found either.
To my mind there are two possible solutions.
1) As suggested in the case, when a file without extension is
specified (i.e. ending in a period) no default extension is
applied. So if the file myfile. is not found and we're on
*ix, we should repeat the search for myfile
2) Allow for a 'special character' to be used at end of a path or
filename to explicitly suppress default extension usage.
What would be an acceptable character to signal suppression
of extension defaulting? A trailing colon? Would that work?
3) Leave as is - *ix users then will have to rename all their
macro/copy files to have a proper extension
Maybe there are other solutions that I'm not seeing.
I would like to know how our *ix users feel about this.
If you are a *ix user, would you please share your preferred
solution?
Thanks in advance,
Abe
===
d...@higgins.net
Abe, all
I’m not a current lx user but have been during z390 development in the past.
I would prefer to see all files used by z390 tools have a file suffix. It helps positively identify file types in directory lists and minimizes code required to check for .mac suffix or none.
--
You received this message because you are subscribed to the Google Groups "z390" group.
To unsubscribe from this group and stop receiving emails from it, send an email to z390+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/z390/74adf91c-f897-fe9e-0232-eb9aeb50d6f5%40bixoft.nl.
Tony
Tony Thigpen
407-474-0770
Abe Kornelis wrote on 4/9/22 08:13:
>
> I have been looking into RPI 1633 / Issue 204 -
> https://github.com/z390development/z390/issues/204
>
> On Unix systems it is impossible to refer to a macro file if it has no
> extension. On windows there is no distinction between [.] and [], but on
> Unix the distinction is relevant. Please adjust code to make sure on
> Unix systems a path ending in dot is interpreted as meaning to find a
> file with or without the trailing dot.
>
> --> So the problem is that Unix differentiates between filenames ending
> extension makes it impossible on Unix/Linux to use macros that do not
> have an extension, not even a trailing period.
>
> The primary example of this issue occurring is with the MVS3.8 maclib,
> which holds macros GETMAIN using just the MVS ember name.
> To set up a path for including these macros z390 expects
> actual file name. using * instead of *. is no option, as that prompts
> z390 to use the default extension of .mac - obviously *.mac will not be
> found either.
>
> To my mind there are two possible solutions.
>
> 1) As suggested in the case, when a file without extension is specified
> (i.e. ending in a period) no default extension is applied. So if the
> search for /myfile/
> 2) Allow for a 'special character' to be used at end of a path or
> filename to explicitly suppress default extension usage.
> What would be an acceptable character to signal suppression of
> extension defaulting? A trailing colon? Would that work?
>
> 3) Leave as is - *ix users then will have to rename all their macro/copy
> files to have a proper extension
>
> Maybe there are other solutions that I'm not seeing.
>
> I would like to know how our *ix users feel about this.
> If you are a *ix user, would you please share your preferred solution?
>
> Thanks in advance,
> Abe
> ===
>
>
>
>
> You received this message because you are subscribed to the Google
> Groups "z390" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to z390+uns...@googlegroups.com
> https://groups.google.com/d/msgid/z390/74adf91c-f897-fe9e-0232-eb9aeb50d6f5%40bixoft.nl
John Ganci
To unsubscribe from this group and stop receiving emails from it, send an email to z390+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/z390/6b901bc5-ce5d-9a58-01d4-77da84248088%40gmail.com.
Abe Kornelis
All,
Seeing your responses,
I will not change current logic.
On Unix copybooks and macros in files having just a member name
without extension
cannot be used without renaming them.
The burden then lies
with the developers to rename any such file
to use an extension.
Kind regards,
Abe
===
war...@swbell.net
Would it be possible to assemble a program then take the text file and link it on z/OS?
d...@higgins.net
Ward
Z390 obj files were designed to be compatible with OS linker and I know it worked back in earlier days. I have not tried it lately.
--
You received this message because you are subscribed to the Google Groups "z390" group.
To unsubscribe from this group and stop receiving emails from it, send an email to z390+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/z390/00b201d9278b%24eb64ced0%24c22e6c70%24%40swbell.net.