John Actually Hursley - eventual home of CICS - has my prize for the case of a non- native product having the most useful description of something which the product did not "own". There may be better instances - and if so they would be rare - but this one is mine.
Just to try to keep up my approach to posting in IBM-MAIN which is actually to back up what I say with suitable references, I found what I guess is the latest GDDM bookshelf and discovered that what I remembered of this excellence is the section "GDDM Devices" in the GDDM System Customization and Administration manual. So in case anyone who might need to know happens to be reading this, if you want to know about 3270 mode table entries - and not just presentation space dimensions - this is probably even a better reference source that the 3174 Functional Description manual! - Otherwise - and I fear I have to take the risk of utterly ruining Peter Hunkeler's day - the usual principle that, the further away you are from what you are describing, the less likely you are to get it right - veering towards actually getting it quite wrong[1]. Distance in this case being whether what you are describing is the product your "shop" "owns" - or - is a product to which you are obliged to make a reference. And just to cover Thomas Chicklon's "Malvolio's letter", products with inappropriate references in their customization "names" through to mistaken information in their manuals are obviously created by the folk responsible for the products themselves and thus can be and are described as "official" manuals. I've said it before and for those who seem to suffer from reading difficulties I'll say it again, the only useful documents to rely on are those which describe the key product itself. Although some contagion infects the manuals on the z/OS UNIX System Services bookshelf, mainly as a result of the "intern" or whoever who wrote the Health Checker up, this shelf clearly only uses the dread 3 initials in remarkably few fits of forgetfulness. - [1] This is only for deep specialists in "legacy" communication products and protocols. The example that has me metaphorically at risk from nearby sharp objects is VTAM trying to handle an X.25 NPSI enhancement. http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/F1A1B6A0/5.5.4.6 describes the DCODE operand of the MODEENT macro used to create mode table entries. The poor lambs authoring the VTAM manual have made very heavy weather of an X.3/X.29/X.28 topic which X.25 NPSI exploited in order to support an SNA character set (SCS) functions "inhibit presentation" (INP) and "enable presentation" (ENP) used by TSO - among programs supporting an LU type 1 without function management headers (3767) appearance - in order to prevent the exposure of secure fields such as passwords. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bald2001/3.3.6 is one description of what this is all about. It's almost by accident that there is any correspondence between this any what the poor lambs wrote! http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/bald2001/APPENDIX2.2.1.6 is the reference which links the two descriptions. Actually, even reading both these descriptions, you'd see just the thin thread of correspondence but you wouldn't have much of a clue what it was all about. Since the introductory notes to this topic from my X.25 NPSI presentation cover sufficient of the topic to satisfy the curious - I hope - I may as well include them here: <PAD Password Protection> Applications which support LU Type 1 without function management headers, may employ two SCS characters, ENP (enable presentation) and INP (inhibit presentation), in order to support the entry of password data. - The INP character is designed to cause subsequent entered data *not* to be copied to the presentation surface of the device - The ENP character is designed to cause subsequent entered data to be copied to the presentation surface of the device as usual, thus removing the effect of the INP character. Prior to X.25 NPSI Versions 2 and 3, an application is expected to remove these characters when converting output data from SCS to the EBCDIC translation of the ASCII character set required by Asynchronous ASCII devices attached to a PAD. X.25 NPSI Versions 2 and 3 will accept these ENP and INP characters in the data stream from the application. "Integrated PAD" support removes these characters and takes action to try to ensure that any data entered between the receipt of an INP character and an ENP character is not displayed on the presentation surface of the Asynchronous ASCII device. An application, such as TSO, can discover whether ENP and INP characters may be left in the data stream, and thus have the entry of passwords protected, if the session is started using a mode table entry which specifies DCODE=X'80'. The specification of the DCODE byte is passed to the application in control vector X'2F' within the CINIT request. </PAD Password Protection> - Chris Mason On Tue, 3 May 2011 14:19:25 -0500, Chase, John <[email protected]> wrote: >> -----Original Message----- >> From: IBM Mainframe Discussion List On Behalf Of Frank Swarbrick >> >> Just to unnecessarily add fuel to the fire, the following is a CICS SIT >> parameter: >> >> USSHOME >> The USSHOME system initialization parameter specifies the name and path >> of the root directory for CICS® TS 4.1 files on z/OS® UNIX. > >Submit a SHARE Requirement asking CICS Development to change it to, say, CICSROOT. > >Or, if you want to "play with" the context-illiterate, create the appropriate z/OS UNIX directory and specify USSHOME=USSMSG10 or similar. :-) > > -jc- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
