John
Although it might be possible to concoct a useful system not using VTAM?
I don't really think it is possible to run a z/OS shop without VTAM, ...
Gerhard couched his words with care - or maybe it was accidental! He said "not using" thereby acknowledging that it could be *impossible* - until I'm reliably informed otherwise - not to have VTAM "available". "Not using" would mean that you haven't taken the trouble to customise the SNA component of z/OS Communications Server - VTAM - and to cause an address space running VTAM to become active - although everything you would need got installed for you with z/OS. The paragraph above was what I initially wrote but then, covering the "TRLE topic" later, I realised that, possibly[1] unless, when running the IP component of z/OS Communications Server, you avoid all the "interface" types which depend on the explicit or dynamic definition of TRLEs, you're going to be "without a paddle" unless a VTAM address space has been started - even if VTAM has no "external tentacles".
I don't think TCAM is supported any more.
I have a vague memory that the last manifestation of TCAM required VTAM "underneath" as it were. I think this faint echo dates from the early to mid-1980s.
Hum, I guess a large enough shop could run z/OS without VTAM ...
If your z/OS system performed work only as batch jobs and all customisation was performed through shared data sets and nobody ever needed to monitor the system other than by use of "after-the-fact" printouts and maybe a few other limitations, you might be able to do without any communications facilities whatsoever ... Which brings me to that administrative matter to which I alluded before, namely, is it possible not to have z/OS Communications Server available with your z/OS? As you can tell, I have not been involved with these sorts of administrative considerations.
Of course, some of the TCPIP I/O is done via VTAM. Weird, but VTAM controls the TRLEs for the OSA.
Two points here: 1. Most obviously, one of the two, the IP component or the SNA component, has to be in charge when the "interface" logic is *shared* as in the case of the cross-system coupling facility (XCF). More generally from the z/OS Communications Server SNA Resource Definition Reference manual: <quote> 2.13 Transport resource list major node ... An MPC connection can be used for both SNA & TCP/IP application traffic. See z/OS Communications Server: IP Configuration Guide. Any user of the connection is referred to as an upper layer protocol (ULP). ... </quote> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b6c0/2.13 and <quote> 2.13.3.7 MPCUSAGE _MPCUSAGE=SHR_______ >__|____________________|__> |_MPCUSAGE=_ _EXC_ __| |_SHR_| statements: TRLE dependencies: MPCLEVEL=HPDT Specifies whether multiple usage (sharing) or single usage (exclusive) of an MPC (with HPDT) group is allowed. This keyword is ignored for non-HPDT capable MPC groups. Users of the MPC group are the various protocol stacks (for example, APPN or TCP/IP). MPCUSAGE=SHR Indicates this group can be used by multiple protocol stacks at the same time. MPCUSAGE=EXC Indicates this group can only be used by a single protocol stack at a time. The first to activate the group becomes the exclusive user of that MPC group. All subsequent activation attempts (while the group is in use) will be rejected. Defining exclusive usage will provide improved performance. </quote> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b6c0/2.13.3.7 2. The decision over which of the two components should be responsible for "interface" logic which could be shared and, following that, should be responsible for enhanced uses which IBM in its wisdom decided should be supported only by the component in the ascendancy,namely the IP component, with a touch of employment protection(!) depended on which component was - ahem - rather better at this sort of job. Thus the task was assigned to the folk behind the SNA component. The consequences of this decision can be appreciated by reviewing the types of "interface" logic which the world cares about these days as the world has been "steered" by IBM recommendations. For example, with the exception of MPCOSA which is a hangover from the days of the OSA-2, all the IPv6 interfaces mimic those for IPv4 which require the explicit specification of a TRLE in VTAMLST - unless the TRLE definition is covered by dynamic definition through the DYNAMICXCF parameter of the PROFILE IPCONFIG statement. Thus all development of the "interface" logic since the old "TCP/IP for MVS" and VTAM products "merged" in order to become z/OS Communications Server has been handled by the VTAM development folk. The existence of explicit or dynamic TRLEs - actually or logically in VTAMLST and "visible" using VTAM DISPLAY commands - has been an external characteristic of this development effort. Footnotes follow in a separate post because of the severe limits of the list!!! ----- Original Message ----- From: "McKown, John" <[email protected]> To: <[email protected]> Sent: Tuesday, December 27, 2011 2:08 PM Subject: Re: Display related operations in assembler.
-----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Gerhard Postpischil Sent: Tuesday, December 27, 2011 12:16 AM To: [email protected] Subject: Re: Display related operations in assembler. ... Although it might be possible to concoct a useful system not using VTAM?
I don't really think it is possible to run a z/OS shop without VTAM, unless you also have z/VM. Why? z/OS requires an IODF to run. IODFs are created using HCD. Which is an ISPF application. Which requires TSO on a 3270. Which requires VTAM. The only TSO 3270 "access methods" that I have ever known are TCAM and VTAM. I don't think TCAM is supported any more. But there may be a way to do HCD type work in batch that I am unaware of. Hum, I guess a large enough shop could run z/OS without VTAM if they did the HCD work on a different system. Of course, some of the TCPIP I/O is done via VTAM. Weird, but VTAM controls the TRLEs for the OSA. Of course, this leaves non-OSA connectivity such as through a CISCO device (we had one defined to TCPIP as a CLAW device - SCTC). So I guess a shop could use TCPIP connectivity. CICS would use only Web access (no 3270). I don't know about RD/z instead of TSO. NFS mount z/OS legacy datasets in order to maintain things like PARMLIB via a UNIX shell, or use RD/z. Ack! Ptui! I'd ROFLMAO if a shop actually did this. I guess (E)JES could be used instead of SDSF since it appears to have a Windows client.
...
-- John McKown
