EXCELLENT observation
Postel's Law should be followed
https://en.wikipedia.org/wiki/Robustness_principle
Consumer systems REGULARLY have blanks in filenames, which makes
scripted automation difficult. Other punctuation can also be troublesome.
-- R; <><
On 3/27/25 10:52 PM, Joel Ewing wrote:
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
--
-- R; <><
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
