Since when has *object* been stored in libraries generally found in STEPLIB?
Most people throw away object after link edit because *LOAD* is what is executed. Don't want to confuse this guy any more than he no doubt is by now... On Wed, May 11, 2011 at 1:13 AM, Chris Mason <chrisma...@belgacom.net> wrote: > Quasar > > As a COBOL programmer in an installation, you need instructions over how to > access TSO which are specific to your installation. You cannot find this is > any > manual provided by IBM. > >> Just out of curiosity, ... > > Does this mean you have such instructions and you can access TSO without > difficulty but you just want to know how it all works? > >> ... I would like to know, how Mainframe Startup Screens (the first screen > that you see, when you connect to a Mainframe Server, and where you would > type TSO) are written. > > Now I digest the rest of this post, I think the answer is yes, I stupidly > read "where you would type TSO" as "where would you type TSO" even > without the question mark! > > The first display image you see once - I guess - you have started up your > TN3270 client and connected to the TN3270 server, as supported - again a > guess - by the z/OS Communications Server (CS) IP component, is an > Unformatted System Services Message 10. > > - > > We must pause here and I have to ask you to take care that you are not in > the vicinity of sharp objects! Since I don't want to have to key "Unformatted > System Services" every time I wish to refer to this function - or even > use "copy and paste" as just now - I need to introduce you to its abbreviation > as defined in > > http://www-01.ibm.com/software/globalization/terminology/u.html > > It is "USS". Now you may be under the impression that this stands for "UNIX > System Services" but despite massive misuse throughout cyberspace, this is > actually wrong - as you can easily see from that IBM site URL. > > It is my opinion that people who misuse the initialism[1] should be aware of > the shock such a reversal of understanding could cause to folk relatively new > to z/OS. > > Be aware that I will refer to USS commands and USS messages. These > commands and messages have nothing whatsoever at all in this planet to do > with z/OS UNIX System Services (z/OS UNIX, to use the correct abbreviation). > > Now that you have reset your understanding of this matter, we can proceed. > > - > >> I have heard they use VTAM Commands. > > In fact, no VTAM commands are involved as you will find them described in the > CS SNA (VTAM) Operations manual. > > Case A. If, as I guess, you are using the TN3270 server, the commands you > enter were set up by your CS systems programmer - who probably has skills > extending to both of the components, the IP one covering the TN3270 server > and the SNA (VTAM) one. In that case the USS commands you enter are > processed by the TN3270 server in order to present the appearance of - to > keep it simple - a display terminal to TSO over an SNA session. I always like > to > describe this configuration as a TN3270 TCP connection concatenated to an > SNA session. > > Case B. If on the other hand you are *not* using the TN3270 server but your > workstation is connected over a data link which supports protocols which can > handle the connection-oriented traffic required by SNA[2], then the USS > commands you enter are processed by VTAM. In this case, you could say they > are "VTAM commands" but that is a misleading avenue to follow. > >> Is there a particular member in some system library, which contains the > actual Startup Screen code? > > There is definitely one and you should easily be able to locate a second, the > one you probably really want. > > I'll explain! > > In case A (TN3270), the one you should be able to find easily is the member > of the library in the typically concatenation of partitioned data sets > (libraries) > containing *object* modules which logically uses the STEPLIB DD-name in the > procedure used to support the TN3270 server address space. There may not > actually be a STEPLIB so check with the appropriate systems programmer. > > The name of the member is the name which is specified by the relevant > USSTCP statement in the PROFILE data set used by the TN3270 server > program. If you have a complicated TN3270 PROFILE data set, you will need > some help from the responsible systems programmer again. > > In case B (VTAM), the one you should be able to find easily is the member of > the library in the typically concatenation of partitioned data sets > (libraries) > containing *object* modules which use the VTAMLIB DD-name in the > procedure used to support the VTAM (named NET, typically) address space. > > The name of the member is the name on the USSTAB operand which is > specified on the VTAM LU statement or the LOCAL statement which > corresponds to your workstation. I guess you are going to need the help of a > systems programmer who understands the VTAM environment to help you here. > > Having keyed "LOCAL", I appreciate that you may be using the OSA-ICC > feature in which case there is a case C, similar to case B in that the > information for which you are looking is in VTAM data sets but similar to case > A in that you are using a TN3270 client. The TN3270 server in this case is > supported by the OSA-ICC feature and it gives the appearance of a pre/non- > SNA local 3270 display device to VTAM. > > Communications is all "smoke and mirrors"! > > But we still haven't got to what you probably *really* want to see which is > the *source* of the set of definition statements, assembler macros, in fact, > used to build the object module whether used by the TN3270 server (not the > OSA-ICC one but the CS IP one) or VTAM. > > If your systems programmers had attended my classes of old, they would > know that the recommendation was to store the source files in the VTAM > VTAMLST data set using the same name as is used to store them in the > object partitioned data set. Why? So you would always know where to find > them! As it is, they may not have adopted this policy and have them stored > away somewhere else. Again you are at their tender mercies. > > Finally, you are not dealing with WYSIWYG files here and so, even with the > source files at your fingertips, they may appear largely to be gobbledygook. > > If you really want to understand what the macros in this file do, here are two > URLs for z/OS V1R12 - although the level is unimportant: > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B6A0/5.11 > > http://publibz.boulder.ibm.com/cgi- > bin/bookmgr_OS390/BOOKS/f1a1b3a0/2.2.1.4.15? > > The first is the VTAM manual which is the authoritative one. The second is the > CS IP manual needed to cover where the object modules should be stored if > you are using the CS IP TN3270 server - in just the last paragraph of the > page! > > - > >> I know, this may not be the right place to ask such questions, but I don't > know any other forums or mailing lists specific to it. > > This is certainly a very good place to be asking - I guess not least because > you might get a more extensive answer elsewhere but I, for one, would like to > know where! > > It's a particularly good place to be asking right now because there are a > number of list subscribers who very much need reminding that this function > exists, is alive and kicking and solicits interest - especially in those among > whom I assume you belong who are relatively new to z/OS. > > There is another list which looks after matters more specifically concentrated > on mainly z/OS CS. The emphasis - as everywhere these days - is on the > functions within the IP component but because one important function is > Enterprise Extender, queries on this topic tend to be asked there and thus the > list becomes extended also to cover VTAM. > > For IBMTCP-L subscribe / signoff / archive access instructions, send email to > lists...@vm.marist.edu with the message: INFO IBMTCP-L > > - > > [1] There are some who, despite knowing the correct use, persist in the > misuse and you will currently find a plethora of threads in IBM-MAIN trying to > uphold this erroneous position - very obstinate characters indeed! > > [2] Which could include Enterprise Extender and so you could still in fact > have > the connection wholly or in part supported by an/the IP network. > > - > > Chris Mason > > On Tue, 10 May 2011 08:32:34 -0400, Quasar Chunawala > <quasar.chunawa...@gmail.com> wrote: > >>Hi, >> >>I am a COBOL Programmer. Just out of curiosity, I would like to know, how >>Mainframe Startup Screens(the first screen that you see, when you connect > to >>a Mainframe Server, and where you would type TSO) are written. I have > heard >>they use VTAM Commands. Is there a particular member in some system > library, >>which contains the actuaal Startup Screen code? >> >>I know, this may not be the right place to ask such questions, but I don't >>know any other forums or mailing lists specific to it. >> >>Thank you very much. >> >>Quasar Chunawala, >>Author, Mainframes360.com >>Cell : 9930389084 >>E-mail : quasar.chunawa...@gmail.com >>Blog : http://www.mainframes360.com > > ---------------------------------------------------------------------- > 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 > -- Wayne V. Bickerdike ---------------------------------------------------------------------- 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
