Paul Gilmartin wrote: >The antiquated TSO restriction is armament for managers >who oppose moving applications to z/OS.
Microsoft Windows supports only 26 drive letters, an "antiquated restriction" lifted from CP/M. CP/M might have inherited drive letters from CP/CMS (minidisks). CP/M debuted 43 years ago. Microsoft Windows also still has 80 column command line windows. The 80 column width dates back to 1928 with IBM's introduction of 80 column punched cards. Are these "antiquated restrictions" problems? In fairness, no. Windows has supported volume mount points for many years, and the use of drive letters is optional or at least trivial. You get 26 drive letter "shortcuts" to spend wisely (and to keep certain older applications happy), but you don't need those shortcuts to access storage. Volume mount point names can also be short if you wish, and volume spanning means the single Drive Q (or whatever) can cross multiple disks. Moreover, although 80 column command line windows are the default and quite common, there's no obligation to use them, especially in typical end user situations with mice, touch screens, proportional fonts, pull down menus, etc. It's the same with z/OS. The O in TSO is "Option," after all. When I use Cognos to get some reports from a DB2 data warehouse, I'm using z/OS a great deal but not using TSO at all. (And my user ID is quite lengthy.) z/OS systems serve billions of users, but the vast majority don't have TSO IDs. That said, it'd be "nice" if TSO-compliant IDs had no additional constraints. It'd also be nice to have more than 26 drive letters in Windows. I cannot think of a platform that does not have "antiquated restrictions." To pick another example, Apple just introduced the iPhone 7. The iPhone 7 has several antiquated restrictions. One of them is the number of display pixels. Even though competing smartphones have more pixels and more dense pixel counts, Apple hasn't budged since the "antiquated" iPhone 6. (And the iPhone 6 pixel count and density was heavily constrained based on prior decisions.) That's because application compatibility is quite important. Changing the number of pixels now, "too soon," would break too many applications. There are *always* political arguments available, mostly dumb ones, if that's somebody's thing. Do the hypothetical restrictions matter? Occasionally yes, usually no. If you're struggling to port an application to TSO (specifically) because of TSO's user ID length limit -- or if the TSO user ID limit is otherwise preventing you from getting something business-valuable done -- please let "your friendly IBM representative" know. Tony Harminc wrote: >What, in this context, is an MVS subsystem? ...And where is this >text from -- evidently not the RACF Security Administrator's Guide? You are allowed to take a look at the Administrator's Guide. :) But here's a copy/paste: "TSO and MVS also require that the first character of user IDs be uppercase A - Z, # (X'7B'), $ (X'5B'), or @ (X'7C')." So what does "MVS" mean in this context? The Administrator's Guide doesn't say. "Not z/OS UNIX System Services" is a reasonable answer, but it might be a partial one. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
