Continued ... -
[1] There's a curious use of the words "Generated by VTAM" in the rows in the "TRLE Definition" column of Figure 1, "Summary of DEVICE and LINK statements" for the "legacy" "interface" types - including "CLAW"! I'm not sure I believe this! I can see no reason why any of the associated logic needed to be changed during the "merger" and VTAM have anything to do with it. I guess someone without the need for any of the "interface" types not needing explicit or dynamic TRLEs should try running without having a VTAM address space and see what happens. Someone who still has OSA features with CHPID type OSE (pretending to be 3172s) might be able to try it. Well while reviewing this post, I figured there may be a hint in one of the messages manuals and, indeed, two points arose: 1. VTAM must be active in order to allow START statements/commands to function initially. <quote> 4.59 EZZ4330E EZZ4330E TCP/IP DEVICE START(S) WAITING FOR VTAM Explanation: TCP/IP cannot process Start Device commands until VTAM initialization completes. System Action: TCP/IP queues all Start Device commands and will process them when VTAM initialization completes. Operator Response: Start VTAM. </quote> 2. VTAM need not necessarily be active all the time! <quote> 9.509 EZZ9671E EZZ9671E tcpstackname DETERMINED THAT VTAM WAS INACTIVE FOR AT LEAST timevalue SECONDS Explanation: Sysplex problem detection determined that VTAM was not available. tcpstackname is the name of the TCP/IP stack. timevalue is the number of seconds that VTAM was not available. System Action: TCP/IP continues. ... Operator Response: Start VTAM. If VTAM successfully starts, this operator message will be deleted. ... If NORECOVERY is active, no further actions are needed. System Programmer Response: If VTAM cannot be started, contact your IBM support center with the system log. ... </quote>
Although it might be possible to concoct a useful system not using VTAM?
So the answer to Gerhard's point is that doing without VTAM is impossible if you want to activate any interfaces in the z/OS IP node which - I would contend - vitiates "a useful system". - Chris Mason ----- 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
