In Unix* it does still depend on the underlying filesystem, of which
there are many.
On Linux, common filesystems include EXT2, 3, 4, and BTRFS, as well as
XFS, and of course ISO-9660.
Windows NTFS (supported with limits on Linux) is there too, as well as
Windows FAT/VFAT/exFAT.
I regularly get errors when I make a backup to a flash drive (usually
VFAT or exFAT) and forget to exclude files with COLONS in the name.
It's not uncommon to name a file with UTF-8 instead of ASCII. And then,
remember, USS filesystems work similarly but are prone to represent
names in EBCDIC.
*using Unix in the generic sense
I have mixed feelings about the anticipated April 8 announcement.
Expansion is good as long as they don't break anything.
-- R; <><
On 3/27/25 7: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 to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [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 to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [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
