Saying that any 8-bit combination is "supported" in file names and paths
by Unix is misleading. It would be very bad form to use a character
code that is not associated with a standard displayable glyph, even if
the creation of such a file were allowed, because reliably working with
a file with "invisible" characters in the name after creation would be
impractical. Special characters like single-quote, double-quote,
asterisk, question-mark, etc. may be allowed, but are inadvisable
because of their special semantic significance when referring to files
in commands and standard utilities causes problems, Any broadning of
file name rules in z/OS would most likely need restrictions based on
usage context as well.
What is allowed and sometimes useful in current versions of Linux and
Windows is almost any other arbitrary standard Unicode glyph in file
and path names, represented in UTF-8. I would assume that multi-byte
characters count as that many bytes against the 255-byte limit. You
can use characters in non-Latin alphabets and even use special symbols,
such as in the file path
*~/gov_SNAFU/👊🇺🇸🔥.txt , *provided all the utilities you plan to use
with the file support fonts that provide the appropriate glyphs and the
system allows you to represent Unicode characters -- in this case u+270A
(✊), u+1F1FA u+1F1F8 (🇺🇸), and u+1F525 (🔥) -- by some means that
isn't too tedious. Linux provides Unicode text entry support globally
at the Operating System level. Windows unfortunately requires that
support to be provided by individual applications, and not all provide it.
JC Ewing
On 3/27/25 6:17 PM, Thomas Berg wrote:
Googled to a wikipedia page:
https://en.wikipedia.org/wiki/Filename
Interesting, there seems to be a common (?) Unix standard of 255 for the
file name. And any 8-bit combination except / and null. Very simple and
straight forward.
Other systems seems to like to complicate things.
But no mention of path lengths. Implementation specific?
Speculating: maybe in z/OS use 44 (?) chars for a "key" to the file/dataset
in z/OS, that is any 8-bit (352-bit) combination, with e g using x'FF' in
the first byte to differentiate from "normal" dataset names. And a
separate "directory"/mechanism to translate from/to the key with the
readable name used by the users.
This way only storage space would limit the length of the names (in
practice).
E g text written here by me could be used as a file name/datasetname. (Not
that you neccessarly would want to do that in normal applications.)
In practice we would want to work with much more limited name lengths as it
would be more managable by the brain, but I could se lenghts of around 130
to be useful sometimes (with modern screen space in 3270).
Thomas Berg
Mundus Vult Decipi
Den tors 27 mars 2025 12:29Mike Schwab <
[email protected]> skrev:
z/OS Unix System Services imposes a 1024 name length limit. A few
directories exceed this and is corrected by CD brfore re-extracting the
affected files.
On Thu, Mar 27, 2025 at 6:20 AM Thomas Berg <
[email protected]> wrote:
How about UNIX/Linux name standard limits? What lengths are permitted?
(And what hex code ranges etc?)
Are there any consensus?
Thomas Berg
Mundus Vult Decipi
Den tors 27 mars 2025 01:22Seymour J Metz<[email protected]> skrev:
Sigma? You don't have to go as far as SDS; IBM had that too, in TSS.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
________________________________________
From: IBM Mainframe Discussion List on behalf of Paul Gilmartin
Sent: Wednesday, March 26, 2025 6:05 PM
To:[email protected]
Subject: Re: Expand DSN names (WAS : Java saved IBM Z?!)
External Message: Use Caution
On Wed, 26 Mar 2025 21:25:01 +0000, Pew, Curtis G wrote:
...
Things that can already exploit zFS would have no trouble exploiting
this. Also, programs that use QSAM or BSAM can in many cases run just
fine
using Unix files instead of MVS datasets. IBM should make that even
easier,
and provide more ways for other things to exploit Unix directories and
files, instead of depending on a 60 year old storage architecture that
seems to clearly have been a mistake from the start.
Moving the search to the control unit was an idea clever for
its time but which gained little traction.
A co-worker once told me of a Sigma system which kept sourde
files in a sort of KSDS, keyed by the statement number. Records
could be added, deleted, or edited without rewriting the entire
file. Another innovation dead end.
A UNIX antiquarian told me that within his memory directory entries
were 16 bytes: 14 for the filename and 16 bits for the I-number.
Both have been outgrown, but with little pain because those
numbers were parameters in header files or wrapped in system
functions.
I understand that a MACLIB member contains equates, 44 for DSN
length and 8 for member length. If developers had been faithful
to the paradigm, it would be possible to increase those numbers
and assemble an installable OS with larger limits.
--
gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email [email protected] with the message: INFO IBM-MAIN
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email [email protected] with the message: INFO IBM-MAIN
--
Joel C Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
