> From: paulgboul...@aim.com > Actually, no. The vast majority of ISPF applications _are_ case > sensitive (although they don't need to be). If they were case > insensitive, there'd be no need to convert their input to upper case.
I think we're just using a different interpretation of 'case sensitive'. Most ISPF panels convert input to uppercase, so dialogs test for uppercase commands. But if ISPF panels converted input to lowercase, dialogs would simply test for lowercase commands. In other words, dialogs couldn't care less what case something was entered in, as long as it's converted to some sort of standard format that the dialogs can easily test for. This is completely unlike UNIX, where commands cannot be converted to uppercase or lowercase because they're case sensitive. But ISPF commands are not case sensitive, so it's okay to convert them to uppercase or lowercase (as long as it's known in advance which way they're being converted). > I'd like someone to confirm or refute my conjecture that > 'TSO' is detected and handled by the input processor, not by the code > specific to the panel. Yes you are correct; individual ISPF panels don't generally have logic to detect and process ISPF commands. This includes 'TSO' (which is an ISPF command), as well as other ISPF commands such as SPLIT, SWAP, HELP (etc). These and other ISPF commands are all processed automatically by ISPF, and are not processed by the panel. In other words, there is generally no logic in either the panel or the program that displayed the panel that processes regular ISPF commands. There are exceptions, but discussing that would be misleading for the purpose of this discussion. > If the 'TSO' command is processed by the input routine and not > by the individual panel code, it would be a minor change to > swap the order of detecting 'TSO' to before rather than after > conversion to upper case. That would make processing of the > 'TSO' command not only correct, but consistent among all panels. 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? > In Windows, it's easy enough to open a command window > (or several) while editing a file (or several) with WordPad > without disrupting one's edit session(s) and Copy and Paste > among the WordPad and command windows. Isn't this the same as splitting the screen and going into ISPF option 6? In other words, you don't have to disrupt whatever session you happen to be in, and can have a command window where TSO commands can be entered? > If ISPF had this facility, there'd be little point in being able to issue a > TSO command from its command line. Unless I misunderstand, ISPF does have facility. So does this mean the problem is solved? ;-) Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.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
