To help clarify (I hope), The commands that ISPF recognized (TSO, SPLIT, etc.) are not coded in an ISPF program/load module somewhere - they are in a command table. You can modify the one included with ISPF, create your own, etc.
Typically in a panel definition the command line is defined with an _ (pre- defined as in input field with CAPS(ON)), but that can be changed by a panel developer. The ISPF panel i...@prim as shipped uses hex 26 for the command field, and defines it as 'TYPE(NEF) CAPS(ON) PADC(USER)'. I changed it on my main menu so I can support lower case. I did this, not for TSO commands, but for my own ISPF commands which allow access to unix paths. To allow this, I changed the CAPS(ON) to CAPS(OFF), and added a command to uppercase a copy of the command ONLY for the purpose of selecting a menu option. This allows such things as selecting option X (exit) from the menu without regard to case. Note that commands in the command table do _not_ require this - that is, I have no special code to handle commands like 'TSO' - ISPF recognizes the command 'tso listalc' or 'TSO listalc' just fine. It also recognizes 'vw /.some_unix_file' where VW is defined in a command table and /.some_unix_file is a unix file name requireing lower case characters. While I recognize that this cannot be done generically by the ISPF developers for _every_ panel (specifically, the ones that they do not code), it would be nice if panel developers (all of them) would provide for lower case as it becomes more commonly required. The SDSF main menu does not react to my tinkering so kindly. Hmm... I wonder if ISPF could consider the CAPS(ON) to only hold for data passed to the dialog itself. That is, ISPF could display and process the panel as if CAPS(OFF) were coded, but if the data in the field must be passed to the dialog, translate it to upper case. If so, my previous statement might not hold. On Tue, 2 Mar 2010 07:43:14 -0800, Charles Mills <charl...@mcn.org> wrote: >Here's an interesting observation. The ISPF "Edit Entry Panel" (what I have >been calling the edit file name panel) supports UNIX mixed-case file names >in the "Other ... file" field. So ISPF is clearly not converting everything >to upper case. > >Yet "tso foo bar" on the Command===> prompt produces upper case output. > >Not quite sure how to fit that into the "order of upper casing/command >recognition" detective work. > >Charles > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf >Of Dave Salt >Sent: Monday, March 01, 2010 9:46 PM >To: IBM-MAIN@bama.ua.edu >Subject: Re: Mixed case to a CLIST from ISPF command line? > > >When a command is entered on a command line, ISPF checks to see if the >command is recognized as an ISPF command. If it is (for example, if it's >SPLIT, SWAP, HELP, TSO, etc) then ISPF processes the command and the >underlying dialog (e.g. the ISPF panel) is completely unaware a command was >even entered. If the command isn't recognized by ISPF (e.g. if a user enters >DOG, FISH, DOIT, etc) the command is passed through to the dialog. The >dialog can then process the command, or reject it if the command is unknown. > >Suppose 'TsO' is entered on a command line that has (or defaults) to >CAPS(ON). I'm guessing (but not 100% sure) that the panel attributes cause >the command to be uppercased to 'TSO' even *before* the data stream is sent >to the mainframe for processing. If this is true, it means even ISPF itself >has no idea what was actually entered on the command line, and therefore has >no possible opportunity to preserve the original case of the command. > >If this assumption is wrong I'd think it would be fairly easy for ISPF to >preserve the original case of the command. But as this isn't being done, I >have to conclude that the order of processing is something like this: > >1) A user enters a command on a command line and presses an interrupt key >(e.g. ENTER). >2) The data on the panel is pre-processed by the terminal (or emulator) >based on the attributes of the panel; e.g. if the command line is defined as >(or defaults) to CAPS(ON), the command is converted to uppercase. >3) The data stream is then sent to the mainframe, where it is inspected by >ISPF. >4) ISPF converts the first 'word' of the command to uppercase (just in case >it was entered on a command line that isn't defined as CAPS(ON)). >5) If the command is recognized by ISPF (e.g. SPLIT,SWAP, HELP, TSO, etc) >then it's processed by ISPF. Otherwise, ISPF passes the command through to >the underlying dialog (e.g. the procedure that displayed the ISPF panel). > >I don't know anything about data streams and how they're passed back and >forth between terminals and the mainframe, but it would certainly be >interesting if someone on this list could confirm whether commands are >converted to uppercase before they're sent to the mainframe? In other words, >if step 2 above is incorrect and no conversion takes place prior to the data >stream being sent to the mainframe, then maybe there is an opportunity for >ISPF to preserve the original case of the TSO command? > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
