Charles Haven't you noticed that, in recent years, bull-fighting has been deprecated in its heartlands?
> ... (don't shoot me, Chris) ... Why not - when you put yourself in my sights? > ... an entire USS ... path ... The following are the principal - if not the "entire" - paths: 5.11, "Unformatted system services tables" in z/OS V1R13 Communications Server SNA Resource Definition Reference http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b6c0/5.11 12.8, "Logon and logoff requests from dependent logical units" in z/OS V1R13 Communications Server SNA Network Implementation Guide http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b5b0/12.8 (Please accept my apologies in advance if any mention of "SNA" brings on a cold sweat - or raised blood pressure - whatever!) 16.3.29, "USSTCP statement" in z/OS V1R13 Communications Server IP Configuration Reference http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b4b0/16.3.29 16.4, "Telnet USS table setup" in z/OS V1R13 Communications Server IP Configuration Reference 2.2.1.4.15, "Using the Telnet solicitor or USS logon screen" in z/OS Communications Server IP Configuration Guide http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b3b0/2.2.1.4.15 Incidentally, I did a smidgen of checking in the "development" manuals and I discovered that if - as appears to be the case from the context - and the plea! - you mean to refer to something other than the "Unformatted System Services" function present in both of the two components, SNA (VTAM) and IP (in the shape of the SNA-oriented TELNET server), of Communications Server, you could simply have keyed "UNIX" - as in the JCL Reference - or probably more generally "z/OS UNIX" - and your fingertips would not have suffered irretrievable damage - and you would enjoy the warm glow which comes from "doing the right thing"! Yet another incidentally: Failure to abjure the attempted hijacking leads to the following sort of nonsense where orthodoxy can be found in close proximity to heresy: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1d1b0/6.23 And there are some members of the spittle-flecked brigade - CO Brig. MacNeil - who claim there is no ambiguity. Moreover they also deliberately - alright, let's try to be charitable - clumsily ignore the confusion they impose upon novices who, having "enjoyed" a z/OS general education, find themselves working with the TN3270E server or, quite possibly, the OSA-Express feature configured as an ICC.[1] A final incidentally - for now: Has anyone else noticed a not so subtle addition in the z/OS Version 1 Release xx Implementation redbooks between xx=12 and xx=13, SG24-7853 and SG24-7946? This demonstrates once again the curate's egg nature of the redbook collection. This sort of aberration can be expected when, rather than being development authors who are supposed to be disciplined[2], the authors are amateurs, folk like you and me, and review is supposed to be performed by an ITSO "resident" - in former times an assignee from an IBM field post but there's less evidence of that recently - and an ITSO editor - who also may have "off" days! - [1] See "Subject: VTAM USSTAB QUESTION". "From: Howard Rifkind <[email protected]>", "Date: Mon, 9 Feb 2009 14:48:11 -0500" http://www.mail-archive.com/[email protected]/msg89840.html and see "Subject: Re: Mainframe hacking", From: Howard Rifkind <[email protected]>", "Date: Mon, 20 Jul 2009 05:36:28 -0700" http://www.mail-archive.com/[email protected]/msg98995.html for evidence that one of your poor fellow subscribers can be so bemused that, even after having had a little tutorial on the abbreviation used in its correct - originally 1970s - context - courtesy of one C.J. Mason, after a mere 7 months the fact that the correct use was quite different from the incorrect use had been forgotten, so pernicious is the influence of so much misuse. And the members of the brigade pretend it doesn't matter! Note that an URL direct from the IBM-MAIN archive is unsuitable since it incorporates my e-mail address. [2] Although there are far too many careless lapses upon which the spittle-flecked leap in order to justify their untenable position. Nevertheless their vaunting triumphalism can easily be pricked by pointing out that, if someone has taken the trouble to point out the "lapse", it gets corrected. The following, the first instance of the misuse (checked because Brig. MacNeil claimed he had fist seen the misuse 15 years ago - and has been delighting in the misuse ever since) illustrates my point: OS/390 UNIX System Services Parallel Environment: MPI Programming and Subroutine Reference For V2R4, V2R5 and V2R6, SC33-6696-00, the misuse is present: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IPEPRE01/ For V2R7, SC33-6696-01, the misuse has been purged: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ASSPRE00/ Intriguingly enough, - this "component" appeared before the general revision of "OpenEdition" to "OS/390 UNIX System Services", - the "component" has two "sister" manuals where the author(s) - one could say - lacked the imagination of the author of SC33-6696 that Brig. MacNeil found so appealing! http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/IPEBKE01 - Chris Mason On Tue, 31 Jan 2012 07:24:08 -0800, Charles Mills <[email protected]> wrote: >Yes on C++ and no on the makefile. I specify an entire USS (don't shoot me, >Chris) path as input and the compiler compiles the .C files as C++ programs. >It compiles .c files as C programs. It is apparently how the native compiler >works. I don't think and did not say it was a restriction. (I would guess >the compiler will compile foo.bar if you tell it to.) I said "it will *want* >to be a .C" -- trying to make it as likely as possible that the OP avoided >one more problem. > >Charles ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
