Re: Anyone a Unicode Services expert? -- roundtrip conversion
The term 'bijective' is a fairly old one, the earliest reference I found in a Mathematical Reviews index was for 1939.. Anyone who has had a college course in mathematical logic or, yes, set theory is likely to know or have forgotten its meaning. It does, however, have a bad reputation because of its use to intimidate non-mathematicians. The example in Quine's Quiddities under the topic mathematosis illustrates why. Still, it is perhaps better than 'roundtrip', which in ordinary use does not really imply bijective. My wife and I both found that we were measurably heavier after a recent Boston-Roma-Boston trip. Additional efforts were required to restore our status quo ante weights. --jg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How to suppress Message in REXX App
On 6/3/12, Giovanni Santuz gsan...@gmx.de wrote:
Am 01.06.2012 18:43, schrieb Lizette Koehler:
Cross Posting to IBM Main and TSO-REXX
I have a Rexx process that issues the HLIST command. I have been
successful
in trapping the output from the HLIST but have an issue when the message
ARC0138I is issued.
I have tried turning off all of the TSO PROF functions (MSGID, INTERCOM,
etc)
I have tried turning off message for that section of the code MSG('OFF')
Any yet it keeps getting produced so the user has to keep hitting enter
until they are cleared.
This message can be overwhelming if my user requests 100's of datasets
that
do not have an MCDS entry.
Does anyone know if this message can be suppressed from a TSO session?
IF
so, suggestions?
Thanks
Lizette Koehler
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
HI
Use X = MSG(OFF) before the TSO Comand and X = MSG(ON) after
Giovanni
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
--
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: What is a PC Call?
We have discussed elements of this topic over and over again here, chiefly in terms of its difficulties for novices. As Bob Shannon has already noted, it is not at all a new once; but it has to be new to every programmer at some time. When you have a question, look first in the archives of this and the assembler list. (If you pose a question here or there that has been discussed at length recently, you will inevitably get short shrift.) The assembler list is likely to be a better forum for detailed technique questions. They are legitimate here too, but more of the people who can answer them authoritatively hang out there. Let me also offer you the perhaps gratuitous advice to test at least your early code in a sandbox LPAR. It is easy to get PC code very wrong in a way that can compromise an LPAR for use by anyone else, requiring an IPL for recovery. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Can DFSORT do pattern matching?
Kurt Wolf writes: | Has anyone written DFSORT exits in C? I have written a great many of them in PL/I, a dozen or so in C, and even a pair of them in COBOL. There are no significant problems; if language support does not already make an interfacing routine available--for IBM-supplied SLPLs it invariably does---one must write a one-off one in assembly language, but they are literally trivial. (it would of course be possible to do the necessary pointer manipulations directly in C or PL/I, but they are better encapsulated.) I have not been following this thread closely, but I have so far seen no mention of the very good P/M facilities that Perl makes available. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Snap dump question
Scott, Is LECL=125 just a typo for LRECL=125 in your post, or is it LECL in your code too? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Snap dump question
On 5/25/12, John Gilmore johnwgilmore0...@gmail.com wrote: Scott, Is LECL=125 just a typo for LRECL=125 in your post, or is it LECL in your code too? John Gilmore, Ashland, MA 01721 - USA -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Snap dump question
Charles Mills writes begin extract DBB LECL will almost certainly not assemble (as John G. was pointing out, a bit obtusely). Should be LRECL /end extract Equally, 'DBB' should of course be 'DCB'. My point--serendipitously well illustrated by what you typed--was that, since the OP obviously knows that 'LECL'. should be 'LRECL', there was a strong possibility that his typo was a transcription error, defective in his post but not in his code. In reviewing the language I used to make this point I find no basis for the notion that it is obtuse. (It is at once clear and polite, but perhaps I should add that I am capable of being impolite.) While I am responding, I do not much like your 'definition'/characterization of a DSECT. A DSECT is a portable putative storage template. It describes but neither allocates nor initializes a block of storage. Like other preogramming constructs, a DSECT can be misused. You are of course correct that if pointed in the weeds it will yield gibberish and, with luck, a quick ABEND. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBM(r) z/OS(r) Management Facility (z/OSMF)
On 5/24/12, Tom Ambros thomas_amb...@keybank.com wrote: Do it. If you do any policy based networking you'll be happy you did. Incident packaging is nice, we don't use it a ton because we haven't seemed to have had too many incidents for a while but it does make it simpler to get all the diagnostics wrapped up with a bow. It looks like there's a fair amount of development going on with it, it is not like the old wizard setup that disappeared a while back and I already forgot the name of. Even the first iteration of zOSMF was far more useful than that interface, whatever it was called. Take good notes on your sandbox install and the rest is child's play. Upgrades at maintenance time are no big deal if you... took good notes in your sandbox install. Thomas Ambros Operating Systems and Connectivity Engineering 518-436-6433 From: Dazzo, Matt mda...@pch.com To: IBM-MAIN@bama.ua.edu Date: 05/24/2012 10:58 Subject:IBM(r) z/OS(r) Management Facility (z/OSMF) Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu So what do you folks have to say about IBM(r) z/OS(r) Management Facility (z/OSMF)? We have zos1.13 up and running and considering configuring IBM(r) z/OS(r) Management Facility (z/OSMF). Looking to see find out how hard it is to configure and how useful it is? Or any other info you might find useful. Thanks Matthew Dazzo Sr MVS Systems Programmer Publishers Clearing House Port Washington NY 516-944-4816 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBM's first tape drive turns 60 (makes you feel old!)
One-inch tapes were once very common in IBM shops, and I will always associate them with a diversion. This width was of course incompatible with the half-inch one used for acoustical recording, but the magnetic-tape medium itself was not; and it was common, after regular business hours, to find computer-room tape drives being used to slit a one-inch tape into two half-inch ones. One enterprising operator friend of mine--He later became a sysprog who mostly lurks but sometimes posts here--even did a small business in selling slitters adapted to this purpose. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Syslog/Operlog Read Access
| Is it a consensus best practice to restrict read access of | syslog/operlog data to those people with a need-to-know? It is not, not least because the question itself is not well-formed. Need-to-know is a useful notion for highly sensitive information that lends itself to misuse in the wrong hands. For syslog/.operlog the operative question should instead be: Who, if anyone, needs to be prevented from accessing this information? The answer will then usually be no minimally qualified user. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Compiled SYSTEM Rexx exec
Still better, make absolutely sure that you are creating a program object stored in a PDSE. On 5/16/12, Scott Ford scott_j_f...@yahoo.com wrote: Make absolutely sure you are creating a load module, not a CEXEC. The REXX compiler has all sorts of options governing the output of the compiler, and I can vouch that it's sometimes easy to slip up. Cheers, Ray John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Retiring after 43+ years with IBM
I of course wish Frank well in his retirement; but I have ambivalent feelings about it too. He is literally irreplaceable. His colleagues on the DFSORT team will continue to be very helpful; that is their tradition; but I, for one, will not have the same unthinking, all but irrational confidence that---after a short, decent interval for testing---a resolution of any and every SORT and/or ICETOOL problem will be forthcoming here. Ave atque vale! John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Reducing Common Area below 16M line
This thread is deteriorating. It would of course be possible to add to the caveats that have already been registered, but doing so is not likely to be helpful just yet. Ed Jaffe's exposition of how to make more storage available below the line is a model of lucid technical exposition, adequately detailed and operational rather than philosophical; and it would appear that Lim Ming Liang has found it usable and useful. Let's of course try to answer Lim's further questions as they arise, but too much preliminary qualification is paralyzing. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: CSVEDIT using COBOL
People who are familiar with and knowledgeable about IEBEDIT make significant use of it. Others of course do not. This difference is largely generational. When SYSGENs were still required their stage 2s, the job streams generated by the expansion of the system-defining stage 1 macro instructions, often failed (chiefly but not only because real DASD storage requirements had been underestimated). It was then necessary to restart this job stream, beginning typically with the failing job step (and altered DD statements for one or more data sets). In these circumstances one necessarily became very familiar with IEBEDIT, which was used to edit the stage 2 job stream to produce a recovery one. It remains a useful utility, and those who don't use it should study the few manual pages that describe it. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Modern users of old tech
Masochism? A latent death wish? I think not. These examples are variants of the If it ain't broke, don't fix it refrain that we often hear here. Heavy, inappropriate use of obsolete or at best obsolescent technology is one of the identifying characteristics of mainframe shops. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Convert CPU time to MSUs
Factor is in fact a decreasing function of ENGINES. It drops off in a moderately but clearly convex way with increasing values of ENGINES. You need a table of the form ENGINES(1) = 1 ENGINES(2) = . . . . . . ENGINES(n) = . . . There is a recent SHARE presentation that contains such a table. Unhelpfully, I cannot remember its title or who gave it. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Convert CPU time to MSUs
Some experimentation for plausible ranges of FACTOR values strongly suggests that this computation should be done with an appropriate mean in each specific context. My suggestion of a table was thus a more valuable one than I realized when I made it. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: National Vulnerability Database (NVD) Search for Mainframe Vulnerabilities
Just searching the NVD with the argument 'z/OS' yields 20 or 21 vulnerabilities, almost all of which appear to have already been addressed/remedied in current releases of the components involved and some of which are quite old. You should of course check the fix levels for these vulnerabilities against the levels you are using in relevant production (excluding any components you are not using). John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: National Vulnerability Database (NVD) Search for Mainframe Vulnerabilities
Tony Harminc has made explicit a point that I made much too obliquely. The chief uses of the NVD and that ilk is to ensure that the operational software one has in current use includes fixes for the vulnerabilities listed. Note also that for the search argument 'z/OS' NVD output does include at least one vulnerability of a CA product used under z/OS. It is certain that other entities---government agencies, auditors, and the like---will also require reassurance about these NIST vulnerabilities and the state of a shop's operational software; and for this reason I have recommended to clients that they prepare and update weekly a standard report that provides this information. This process can be automated in significant part, at least for software that is maintained using SMP/E; and having such a report and the machinery for generating it in hand will save much time in the future. (It will also make sysprogs who anticipate this requirement look.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: It's feeding time in Jurassic Park . . .
I have firsthand, personal knowledge of just one successful Scandinavian project in which even more ambitious server-virtualization goals were set and met; but one successful project---conducted by serious, highly competent people---does establish the feasibility of such an undertaking. It is thus premature and perhaps worse to label this query a joke or scam of some sort. If it is one, that will emerge; but let's defer judgment for now. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Programming languages can't have copyright protection, EU court rules
Charles Mills has made the operative distinction very clear, but let me try another analogy. Think of yourself, briefly, as Shakespeare. You have written Sonnet XXX, When to the sessions of sweet silent thought I sigh the lack of many a thing I sought. Then can I . . . . . . You, Shakespeare, may copyright this sonnet, its specific content. You may not copyright the fourteen-line sonnet form and its rhyming scheme. Instances of a schema are copyrightable and protectable. The schema itself is not. You may, that is, protect yourself against the misappropriation of a sonnet that you write. You may not interdict the writing of [non-duplicative] sonnets by others. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBMLink Outage May 4-7
IBM should explain what it expects to accomplish during this--on the face of it--absurdly long interval. If IBMLink's deplorable availability will be very much improved after it, this outage may well be justifiable. If not, not. In general, it is time for more transparency about these issues; prior notice without consultation is not enough. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Does C/LE open of DD:ddname(member) use SVC 99 or FIND?
The point here is not what some particular routine oor utility may do or permit. It is what can be done ab initio by an programmer who wants to do it using the HLASM or some particular SLPL . z/OS MVS does permit one to open a PDS as a PS data set in a routine written in assembly language or PL/I, and what one then gets with successive reads are its successive directory blocks. I have done this many times without incident, but I do not of course recommend it to novices. I have not myself done it in C; but Bernd Oppolzer is a careful, highly reliable reporter of his experience; and I am thus sure that it can be done in C too. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
The finding that fewer explicit GOTOs are used and need be used in writing a routine in a statement-level language that makes the standard structured-programming figures available is at once trivial and important. As I noted in an earlier post I tend to use GOTOs chiefly in recursive processing, which the structured-programming theorists have largely ignored. If and when they formalize and implement recursive figures that meet my needs, I will of course use them. Until then I will continue to use GOTOs, implemented as cleanly as I know how in at least locally standard ways. What I have found at once odd and a distressing is all of this late-in-the-day zealotry. I feel no lively sense of guilt when I use a GOTO, and I doubt that programming students shoulkd be taught to do so. GOTOs are and will be infrequent in well written code., but anathema are dubious here and elsewhere. They belong to another, prescientific tradition. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: DSN MYSTERY - CURRENT UTILIZATION GREATER THAN CURRENT ALLOCATION.
The backup is essential if IBM's help is to be solicited. I would ask for that help before doing anything more. I have never seen or heard of such an error, and it may be hard to reproduce. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: A z/OS Redbook Corrected - just about!
No, Shmuel's point is that, while no one gainsays that UNIX Systems Services is IBM terminology, IBM has not associated the acronym USS with it in its 'official listing'. The URL you supply indeed supports his view. In begin extract UNIX System Services An element of z/OS that creates a UNIX environment that conforms to XPG4 UNIX 1995 specifications and that provides two open-system interfaces on the z/OS operating system: an application programming interface (API) and an interactive shell interface. UNIX-to-UNIX Copy Program (UUCP) The command (uucp) that starts file copying from one or more sources to a single destination. A group of commands, programs, and files that allows the user to communicate with another UNIX system over a dedicated line or a telephone line. /end extract the entry for UNIX Systems Services is not followed by an acronym, while that for UNIX-to-UNIX Copy Program is followed by one, (UCFP). This pother has nevertheless gone on long enough, indeed too long, as Schmuel apparently also agrees. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: A z/OS Redbook Corrected - just about!
In my previous post the text (UCFP) should of course be (UUCP) instead. My apologies. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Edward Jaffe's already cited point, that begin extract The behavior of well-defined coding structures like IF/THEN/ELSE, DO, SELECT, CASE, etc. are extremely well understood--both by programmers and by code optimizers no matter which language is being employed. /end extract is fundamentally important. Optimizers distinguish many special cases of each of these figures, generating slightly but significantly different code for each of them. A routine that is comprised chiefly of instances of these figures is thus easy to optimize, and this is often the case even when these figures are used less felicitously than than they should be. An optimizer can mitigate the bad-performance effects of ugly code. It must, however, be remembered that the code generated for, say, a DO WHILE or a DO UNTIL contains and makes critical use of unconditional branches. They are indeed implicit in these two figures and, of course, in IF-THEN-ELSE too. The question when GOTOs, i.e., unconditional branches, should be used explicitly is thus the interesting one. I myself use them where 1) I judge that they confer a significant performance benefit and 2) they can be used in a regular/orderly way. IN looking through code that I have written recently for instances of them I discovered something that I had not really been aware of. I use them most often to unwind recursions and for catastrophic error-handling. If, say, in traversing a binary-search tree recursively in some key sequence I find what I want, I use a 'stack-cleaning long branch' to return to the point at which I began the traversal. This 'out-of-block GOTO' is not strictly necessary; but the alternative, a sequence of several stack-unwinding returns, is ugly and slow. To summarize now, there are, I think, situations in which explicit GOTOs are appropriate, in which their use can confer significant, readily measurable performance benefits. Unfortunately, these situations are also highly problematic. To use GOTOs effectively in them one needs to know more about run-time dynamics than most programmers now know or are, I fear, ever again likely to be taught. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
Gord, Not quite. PL/I is the archetypical; language that makes these facilities available, and in it the label associated with a leave statement can only be that of a containing group, as in outer: do ; inner: do ; . . . leave outer : . . . end inner : end outer ; in which execution of the leave statement transfers control to the statement following the end outer ; statement. The GOTO I described transfers control to the statement following the instance of a label associated with the first invocation of a procedure from the invocation of that procedure in which it is executed. Note that PL/I can do this. If you supply a label constant, call it gubbins, to a procedure as an argument and then, within that invocation or a subsequent, recursive invocation of this procedure execute the statement goto gubbins ; control will be returned to the instance of the label gubbins active at the time of the first call,he DSA stack weill be purged appropriately, etc., etc.. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: A z/OS Redbook Corrected - just about!
Almost all acronyms are overloaded. In some contexts this overloading can be ambiguous, even misleading; in others it is not. All of the arguments about this issue have been set out, chewed over, and regurgitated repeatedly. No consensus has emerged, and none is likely. Can we now perhaps move on to other topics? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
GO TO cobol
Suppose that I wish to do something to each of the elements of an assembly-time array in turn. In the macro language of the HLASM I must write something like |ne seta n'array |i seta 0 |.traverse_loop anop |i seta i+1 |elements_exhausted setb (i gt ne) | aif (elements_exhausted).traverse_lend | . . . process array(i) | ago.traverse_loop |.traverse_lend anop In other languages I can write functional equivalents more compactly. In all of them I can do this of anything else well or very badly indeed. Positive, chiefly one-on-one, mentoring focused on how to code well can be very helpful. Prohibitions cannot. They are always and everywhere unwise. They never ensure that code written using some notionally virtuous subset of a language will have any positive merit. It used to be thought that all would be well with the world when the last king had been strangled. We know better now, but we continue to seek authoritarian, Orwellian solutions to the problem of programming quality. Our world will not be an improved one when the last explicit GOTO has been excised from the last routine still in use somewhere. Bad code and good code reflect the qualities of mind, training, and experience of the programmers who write them; there are no shortcuts available for producing the good kind. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
If we're going to talk about these issues it will be useful to avoid carelessness. There may well be or have been an Edgar Dijkstra, but if so he has been silent about GOTOs. The Dijkstra of interest here was Edsger W. Dijkstra (1930-2002). John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: GO TO cobol
I agree that there is more than one good way to do everything. Gerhard's code is fine. For a loop where it is invariant, I should prefer to save and reuse n'array; and I prefer the boolean assignment statement and AIF |elements_exhausted setb (i gt ne) | aif (elements_exhausted).traversal_lend to his single statement. I even object, but not much, to |.trvend anop , I supply the missing-operand comma for anop, mexit, etc., only when I want to place a comment after it. These, however, are details that are important only as they contribute to coherence. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unix path name
I like Paul Gilmartin's contribution. It is marred only by a small omissis that most readers will remedy for themselves without even being aware that they are doing so. The text | 2) Maximum number of characters in a file in a directory should be changed to something like | 2) Maximum number of characters in a [member] NAME in a directory In a z/OS environment the answer, 255, is enforced by the binder for both member names and their aliases.[The term 'member' is not a pukka UNIX one. It is, however, used in z/OS MVS program management user's guide and reference, V1.R12 , p. 106 and passim.] John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Unix path name
My point was that while 'member [name]' and 'alias' are useful terms in an MVS environment they are without official warrant elsewhere. The word 'pukka' has the usual Sanskrit==Hindi==British English etymology. It meant literally 'cooked' and now means legitimate or high-quality exemplar of. Cognates abound. In Farsi, for example, rare meat is described as 'na pochte', not cooked; and the American 'half-baked', used to describe some ideas and etymologies, may reflect semantic contamination from this source. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Macro Assembler Question
It would be helpful to know what you are trying to do. Try explaining what that it without prejudging the question whether compound variable names are needed to do it. They are available at almost any level of complexity you need, as the identifiers of created set symbols and set-symbol arrays, as in the trivial example |prefixsetc 'Etaoin' |infix0setc 'Alfred' |infix1setc 'Prufrock' |suffixsetc 'Shrdlu' |switchid setc 'prefix'.'infix0'.'infix1'.'suffix' |lclb (switchid) ---identifier is: 'EtaoinAlfredPrufrockShrdlu' |(switchid) setb (t'P2 ne 'O') ---P2= value coded/present? Again, tell us what you want to do. Doing it is almost certainly possible. Berndt's suggestion that this discussion be moved to the assembler list is a very good one. There is overlap among the readers of these two lists, but HLASM language constructs of any complexity bore and discourage people who don't use it regularly. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: EZASMI debugging and stimer routine
A variant of Rob Scott's scheme is to use a classical watchdog timer. Suppose that L is the longest time interval during which it is reasonable to wait for your TCP/IP processing ECB to be posted complete. Define a different WDT ECB that counts down the time interval L . Then every time your TCP/IP processing ECB is posted reset the WDT ECB to begin its countdown again. If the processing ECB is always posted within L time units. The WDT ECB will never be posted. If on some occasion the TCP/IP processing ECB is not posted within the time interval L, the WDT ECB posting interval will expire, it will be posted, and notice to take corrective action will thus be given to your routine. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SNA future
SNA has certainly been eclipsed, often appropriately, by TCP/IP. I am not certain, however, that SNA is even moribund; and it would certainly be premature to prepare the funeral baked meats just yet. In the interval conflicts with the established uses of 'SNA' as the stock symbol of Snap-On, Inc. and as an acronym for the Student Nurses Association have not been problematic. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Detect SVC to Place Caller in Key 0
It is certainly possible to detect some naif SVC-based schemes that return control to their invoker in key 0; it is not possible to do so in general; and it would not be enough to do only that. Moreover, SVC-based schemes to this end are at best obsolescent; PC-based ones will be the villains of the future. Shane has warned me that by mentioning this I am encouraging auditors to erect barriers to the virtuous use of PC-based schemes too, and he is of course quite right. I am nevertheless reminded the USAF DEWLine Project, circa 1952-1992, which did perhaps come to provide adequate protection against over-the-pole incursions of the USSR's atomic-bomb carrying Badger bombers, but only well after those bombers had been retired from service. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Grace Hopper Stories!! (was RE: Pre-Friday fun: Halon dumps and POK Resets)
I like zMan's idea for a two-sided--nanosecond and millimeter--ruler; his notion that the availability of the second, millimeter side would make justifying its cost easy is a really inspired piece of nonsense. I wish I'd thought of it. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Leaving IBM
I've been struck over the years by the relevance and helpfulness of your posts. You don't pontificate, and you don't say more than you know. Let me borrow and adapt from George Orwell's tribute to Gandhi: Compared to most contributors here, what a clean smell you will be leaving behind! John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: A z/OS Redbook Corrected - just about!
Yes, your pronunciation appears to be an acceptable one---'correct' is too normative a word for most linguists---for an educated-circa-2012-somewhere-in-Texas speaker. Still, I don't suppose that I will be expected to forego my usual plea for the use of the IPA instead of such expedients in these situations; and I will not. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: LE C calling HLASM
There are several ways to do what you want to do in PL/I, among them the ways Steve Comstock suggests. I personally prefer o to invoke the HLASM from PL/I using PL/I descriptors, which are easy to work with in assembly language, and o to invoke PL/I from the HLASM using the PL/I descriptors that a PL/I routine expects when it is invoked from another PL/I routine, i.e., to avoid any use of options(asm) anywhere. Descriptors are your friends; they provide generality and power; and they are what generated PL/I code expects to work with. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Endevor(Change Management Software)
There is a long tradition among sysprogs of what is done and not done, and what is done is done within the framework of SMP. There are some few exceptions, but most ISVs use SMP too. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Server time Protocol and CICS
Tony's response deserves high praise, not least because it reflects some historical understanding of how systems evolve. The original design of CICS envisaged making elegant use of the announced facilities of OS/MVT. When the time came to implement CICS 1) some of these facilities were not yet available and 2) some of them did not yet work reliably. The implementers of CICS were thus forced to take a RYO approach. They in effect gutted an MFT partition and installed their own functionally MVT-like facilities in it, calling their storage-management interfacing macros GETMAIN and FREEMAIN, etc., etc. The result was an in many ways a superb table-driven system, one that improved significantly over the succeeding years. Its chief 'defect' was the implementation of its user interfaces as a set of assembly-language macros, which meant that applications run under it had to be written in assembly language. This was 'remedied' in various ways, some elegant and some not, and finally by introducing a 'command'---as opposed to the old 'macro'---level CICS; ultimately it became possible to write CICS APs even in RPG, although these could not be even quasi-reentrant. The major marketing obstacles to its use by other than assembly-language programmers were thus gradually removed. In my own doubtless élitist view CICS never fully recovered from these initiatives. They did enable ribbon clerks to write CICS APs, and opinions about whether that was beneficial differ widely. What is not in my view open to argument is that criticism of the present state of CICS and other such subsystems that is not diachronic is all but certain to be irrelevant. We are all, ineluctably, creatures of our experience. If you don't know the history of CICS, IMS, DB2, whatever, mug it up if you wish to discuss that subsystem; and stai zitt' until you have mastered it. (Controversy will not thus be eliminated or perhaps even much reduced; equally informed views can, do differ sharply; quaint irrelevance will be reduced). John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Leap seconds and the Server Timer Protocol
This is the title of a new this month IBM Techdocs White Paper, WP101091, by Gregory Hutchison, a PDF of which can be downloaded from the IBM Techdocs website. Some of you may well find his discussion of the distinction between the insertion (or, in principle, removal) of a leap second 1) by steering, which accomplishes the insertion|removal incrementally over a period of about 7 hours, or 2) by spinning on a lock for a full second, which does it in one gulp, helpful. Be aware that the next leap-second insertion will be at 11:59:59 UTF on 30 June 2012. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Leap seconds and the Server Timer Protocol
Quite right! It is WP102091. I am suitably repentent. --jg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Leap seconds and the Server Timer Protocol
Paul, The sequence 2012 June 30, 23h 59m 59s 2012 June 30, 23h 59m 60s 2012 July 1, 0h 0m 0s will certainly appear in the transmitted sequence, but its middling term was chosen to call attention to itself precisely because it is NOT a valid date-time value. It appearance does not legitimate the notion that 60 is a valid term in a zero-origin cycle modulo 60. The mathematics of these things has been settled since Gauss. Do you read German or Latin? If so, I'll be happy to supply the Werke citations. Or again, you can search them out yourself on line. Neither should, however, be necessary. (You know very well that only 0 and 1 can appear in a zero-origin modulo(2) sequence.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Leap seconds and the Server Timer Protocol
Radoslaw has made the essential point. Times like hh.mm.60 are rejected as syntactically illicit by time-vetting routines, conversion routines, and the like. Glonass, RS's example, did hang for just this reason. There is a strong consensus among the members of the several international committees involved that leap seconds must not be literally intercalary in the way in which February 29 of leap years is intercalary. z/OS, for example, 'leaves out' such seconds by spinning on a lock for a second. I shall not discuss this matter further here. You are free, as always, to take your own Martian positions on this and other such issues. --jg -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
Since this sort of thing is expected of me, I will note that we find ourselves between Scylla and Charybdis here. Chris Craddock's formulation was open to the exception that Peter Relson took: there is fetch-protected storage the contents of which its owner is entirely free to make available to others. Peter's exception is logically impeccable. It did, however, seem to me to be a very special one; and I observed that it was. I still prefer the ROT that the contents of protected storage should not be made available to the unauthorized (in any but very special circumstances, when they are known procedurally to be innocuous.). To repeat myself now, Peter is nonetheless correct in the abstract. There is a long intellectual tradition which has it that the production of just one black swan is an unanswerable refutation of the proposition that all swans are white. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
Swans, white and black, have a long history in scholastic and then mathematical logic, figuring too frequently in illustrations of modus ponens: All swans are white. A is a swan. Ergo, A is white. The heavy, unquestioning use of this scheme presumably reflects the fact that northern hemisphere swans, European and Japanese swans in particular, were/are white. All this changed when the southern hemisphere, Australian and New Zealand, black swan, Cygnus atratus, was discovered in the late 18th century. Black swan then came to have another, quite different connotation. It is used to describe putatively rare things when they are in fact found and sometimes even to derogate rareness, as in the recent heavy use of variants of Unscrupulous, greedy bankers are not black swans. Produce is used in logic as shorthand for provide an instance of in the sense of the existential quantifier, assert or show there is at least one S such that S is an x. Obtusely, I had not thought about the 'production of a black swan' in its other, literal or Marxist economic sense, accomplished say by painting a white swan black; but I agree that the idea is repellent. (We again have a significant, growing population of white swan pairs resident throughout the year in our glacial ponds/reservoirs here in Massachusetts west of Boston. They are very tolerant of people, and I should not want to see that change.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
In response to Chris Craddock's stricture about the disclosure of the contents of fetch-protected storage Peter Relson wrote begin extract This is not necessarily a violation of the IBM statement of integrity. It depends on whose data is being copied. I am allowed to put my own non-sensitive data into fetch-protected storage and copy it to non-fetch protected storage if I so choose. The requirement is that I not allow the unauthorized user to access something he should not be given access to. Fetch protection is just one tool in the bag of tricks. The owner of the data is typically the one that decides what the access limitations are to be. end extract/ To borrow one of Chomsky's distinctions, this is true, but it is not interesting. I may of course do anything I like with something I myself put into fetch-protected storage. Moreover, I can know, locally and procedurally, when I can do so; but most of the time I am dealing with someone else's fetch-protected storage; and for it the only proper rule is non-disclosure to the unauthorized. An exact, entirely correct description of every action that constitutes a breach of integrity at some time T may just be achievable; but if it is achieved it will be obsolescent when it is achieved; and it will resemble a contract drawn up by an attorney not to inform but to protect a client from hostile litigation. It will not, that is, be at all helpful or even intelligible to any but the already well-informed. Integrity remains a crucial goal. Practices that clearly put it at risk must be avoided, and breaches must be closed as they are detected. (Disagreeable as this sounds, 1) we now learn chiefly from these breaches; and 2) there will be more of them.) ROTs simplify reality, and they thus always entail overkill, but they are useful to people who lack the experience to make subtle distinctions. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
In an earlier post that apparently went astray I noted that the scheme of copying the same non-trivial COBOL program into around 11,000 other COBOL source programs is not---Let me be polite---a desirable one. This single program should be compiled just once; and the object module thus produced should then be linked, specifying NCAL, into a library that is made available for the other compile-and-link operations. This done the binder will resolve the external reference to it in these around 11,000 source programs by including it in the executable load modules produced by compiling and linking them. When this scheme is used the single program they all call will of course be a separate replaceable CSECT in these load modules. The question whether these operations will need to be done again any time soon also needs to be examined. If so, making this common routine a dynamically loaded one should be given very serious consideration (as an earlier poster pointed out in somewhat different terms).Dynamic loading is often used gratuitously; but in this situation, where many other routines invoke the same apparently volatile subroutine, it could very well be useful. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Tips for continuing DD statement with only one parameter field
This thread has very largely straightened itself out. For the record, i.e., for the sake of anyone who reads through it in the archives: 1) parameters and subparameters are of two sorts, positional and keyword 2) many historical keyword subparameters, e.g., those of the DCB= keyword parameter, have been half promoted: they continue to be usable as subparameters, but they may now also be coded as parameters 3) PARM= is a keyword parameter 4) The permissible lengths of the values of parameters vary widely [wildly?] 5) The curious restriction that positional parameters must precede keyword ones has been retained, a long, long time after its relaxation in the HLASM macro language 6) In these and other respects JCL has become a patchwork. It is no longer coherent: a knowledge of some of its facilities does not permit plausible, almost invariably confirmed conjectures about the rest of them to be made. 7) Op. cit. [in the work (already) cited] is a suitable locution for avoiding the repetitive full identification of a document. In standard scholarly usage it must be accompanied by a page number, paragraph reference, or the like; and this requirement is a particularly urgent one when the document in question contains multiple, not entirely consistent discussions of the same topic. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
JCL example to relink a CSECT into an existing load module
Let me try to begin at the beginning. The scheme you used to produce the around 11,000 executables you want to modify was ill-chosen. There was no need to recompile the source text of program BA4C1426 around 11,000 times. Compiling it just once would have been enough. The object module produced by that single compilation could then have been link edited or bound into a convenient library specifying NCAL. Then, when your applications were compiled (WITHOUT including BA4C1426 in them) and subsequently linked or bound---with the library into which the NCAL load module for BA4C1426 was linked or bound made available to these other link or bind steps---the linkage editor or binder would have done the necessary automatically. Now as to your present situation, from circa 1965 forward the various linkage editors and now the binder have supported a REPLACE operation---It is also the delete operation; if you replace something with nothing, something is just deleted---that permits one CSECT to be replaced by another. Please post the linkage-editor [or binder] output for one of your old load modules. If it shows that BA4C1426 is a separate CSECT, a trivial relink or rebind operation with the same REPLACE statement for each of your around 11,000 applications will solve your problem, If not, not. (The ill-advised COPY operations may perhaps, depending upon when they were done, preclude this operation.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: JCL example to relink a CSECT into an existing load module
The scheme Tom Marchant proposes is workable, but it is order-dependent in a way that I find disagreeable. I suggest the use of the REPLACE statement instead. Its syntax is | REPLACE oldsec(newsec) See pp. 63ff of z/Os MVS Program management: User's guide and reference, SA22-7643-10, which includes some COBOL examples. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Customer Service, the good and the bad...
Greg Shirey wrote: begin extract I get your drift, but have to disagree, respectfully. This is a discussion group, not a technical support service. IMO, there are no customers here. /end extract I think Bill Fairchild would agree that an occasional thread here takes the form of a discussion between people who are, to a first approximation anyway, equally experienced and informed. These discussions are agreeable and helpful. They are not, however, the norm; and it would be disingenuous to maintain that they are (because we should like them to be). Most of us, most of the time, are either askers or answerers of questions, with only very occasional role reversals; and this portion of what we do here is better modelled using Bill's terminology than Greg's. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Good source for relationship of opcodes, models, MACHINE() and ARCH()
Charles Mills wrote: begin extract . . . that correlates Model numbers, the HLASM MACHINE() option, and the XL C/C++ ARCH() option, and also the Enterprise PL/I option ARCH() which (believe it or not!!!) is apparently exactly equivalent to that of C/C++. /end extract It is not a secret that XL C/C++ and Enterprise PL/I share the same optimizer and code generator; and it is thus unsurprising that their ARCH levels are the same. Crowded lines sometimes result from defaulting to the option LIST(121)? The option LIST(133) should [almost] always be coded explicitly. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
Edward E. Jaffe wrote: begin extract The above notwithstanding, I don't think anyone at IBM or elsewhere would recommend this technique for brand new, 21st-century development. /end extract and I am very pleased to see that this is his view. My own, slightly different view of this interface is in a certain sense admiring; but it is also very like my view of Kama Sutra position 327,859: I see that you can do it that way, but why? Moreover, as I have had occasion to say here before, its cleverness seems to me to be misplaced or, better perhaps, too provocative. It implicitly poses a challenge of the self-congratulatory form: No impostor is clever enough to penetrate our defenses! This is unfortunate because there are able old-sense hackers who respond only to such challenges. (It is a good operational premise to assume, however improbably, that attackers are as smart as defenders.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Good source for relationship of opcodes, models, MACHINE() and ARCH()
I should guess that the question whether there will ever be a METAL PL/I is more IBM-political than technical. --jg On 3/6/12, Tony Harminc t...@harminc.net wrote: On 6 March 2012 11:25, John Gilmore johnwgilmore0...@gmail.com wrote: It is not a secret that XL C/C++ and Enterprise PL/I share the same optimizer and code generator; and it is thus unsurprising that their ARCH levels are the same. Which leads one to wonder if a METAL option for PL/I exists, or could reasonably exist. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Good source for relationship of opcodes, models, MACHINE() and ARCH()
I don't know whether Tony is the notional culprit or I am, but I can very easily be induced to shut up/avoid your topics, and I shall now do so. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: LAE instruction
I was glad to see Allen Gainsford's mention of the Copy Access, CPYA, instruction. It is too little known and used, as this thread makes clear. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
David Cole and I are, I think, in substantive agreement about the offensive character of this ISV's scheme. That said, the situation we confront would be much worse if this scheme had been used to do real mischief. It has not, and we can take some small comfort---It is only small comfort--- in that. There is an old notion that, shorn of any sexist connotations it may once have had, remains important. It is not enough that Caesar's wife be virtuous; she must also be seen to be virtuous. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: VHow convert historic STCK to local time?
The URL that Dale Miller provided contains the text begin extract One possibility is that the certificates Azure relied on allotted years consisting of only 365 days, rather than the 366 days that are needed once every four years to account for leap years. If that error affected Azure certificates, the cloud platform may have shut down as systems were unable to confirm they were connected to other trusted nodes. /end extract Some few years after Gregory XIII's introduction of AD 1582 many people are still using the Roman/Julian definition of a leap year instead of the Gregorian one. In fact the Gregorian calendar introduced a second-order correction. Years are of two kinds, centurial and non-centurial. Every fourth centurial year is a leap year, and every fourth non-centurial year is a leap year. All other years are common, non-leap ones. Thus: leapchk: procedure(year) returns(aligned bit) reorder ; /* returns true for leap years, false for non-leap years */ declare year signed binary fixed(31,0) nonassignable parameter ; declare leap aligned bit ; declare (H0 value(0), H4 value(4), H100 value(100), H400 value(400)) signed binary fixed(15,0), mod builtin ; leap = (mod(year,H4) = H0) ; if leap then do ; leap = (mod(year,H100) ¬= H0) ; if leap then ; else leap = (mod(year,H400) = H0)) ; end ; return(leap) ; end leapchk ; Code that embodies (or uses via subroutine call) the Julian definition of a leap year is fatally flawed. Grappling with the idiocies of time management is best left to coloro che sanno. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert historic STCK to local time?
David, Perfect-hash schemes are often very useful for match-seeking. They are not, however, usable for bound-seeking--here specifically GLB-seeking--operations that evaluate a step function. Very few of the search arguments--STCKE/TOD-clock values--for which a bound is sought are even present in the table. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: TINC?
Shmuel/Seymour wrote: begin extract NFW. There was only a single partition on PCP. Based on the model I'd guess that you were running DOS/360. /end extract and it is correct, albeit in a Pickwickian sense, that OS/PCP had only a single partition; but it did support both transient and resident readers and writers; there were even some very primitive to-2311-DASD RYO spoolers in use; and at this remove Lloyd Fuller's confusion may be only a terminological one. Still, I too guess that he may have been using DOS. --jg On 3/1/12, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 1330520469.27305.yahoomai...@web180907.mail.ne1.yahoo.com, on 02/29/2012 at 05:01 AM, Lloyd Fuller leful...@sbcglobal.net said: No. When we used PCP on the Model 40 with 64K. We had a single job partition and, most of the time, a spool partition. NFW. There was only a single partition on PCP. Based on the model I'd guess that you were running DOS/360. It was a very simple partition (like 10K or so) that ran the 1401 What are you trying to say? The 1401 was a computer, not a program. If you meant that you ran the 1401 Emulator program, that confirms that it was DOS. If we needed more memory for a specific purpose, we would reipl from a different pack and bring up OS360 with just the program partition. Another sign that you were not running OS/360; on an OS/360 system with multiple partitions you can amalgamated partitions with the DEFINE command; you don't need to re-IPL. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
I don't want to put words in EJ's mouth; but if 'an exposure' were replaced by what I should call 'misuse' what he said is correct and not even controversial. I think there is an exposure, in the sense that this device lends itself very readily to abuse. I have seen no evidence that it has actually been misused in any but the tenuous sense that it adds clandestine overhead to the processing of every interrupt. The device itself has been much misused elsewhere. A number of viruses have, for example, used a Windows scheduled task---PC Health Data Collection is a favorite---to hijack PCs. Moreover, now that its use has been publicized here, the scheme it embodies---not, a fortiori, the offender's code itself---is all but certain to be used irresponsibly by others; even though, as I believe, the the offender's code itself commits no substantive offense it it is, I think, guilty of the admittedly much subtler offense of providing a template for others, who are bent on mischief, to use. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert historic STCK to local time?
I cannot be the only one who finds these discussions tedious. The archives contain more than a hundred threads very much like this one. The same issues are discussed, more or less inadequately, over and over again. Sanely organized networks, even those that do not span multiple time zones, collect and store only UTC [GMT] STCKE values. It is then of course possible to write trivial routines that, given a UTC offset, display or print local clock times, absurd 12-hour ones in the United States [and, apparently, parts of Canada too] and 24-hour ones elsewhere. Insanely organized networks must always collect vector-valued times, i.e., an STCKE value and its associated (fixed-point NOT integer) UTC offset. The raw conversion of STCKE-instruction values without the use of a leap-second table is an indefensible practice that convicts its perpetrator of radical ignorance and/or technical incompetence. The table involved is short; it is ordered; it can be searched using very efficient glb-seeking binary search; this table grows very slowly; elements can be added to it before their effective dates; ample advance notice of requirements to add new elements and their effective dates (always one of two) is provided; etc., etc.[The detailed design of this table should make provision for negative leap-second corrections, but that is a trivial matter.] John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert historic STCK to local time?
Barry Merrill is of course politically entitled to his view. Equally, he is entitled to the view that the earth is flat. The warrant for both is much the same. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert historic STCK to local time?
Paul Gilmartin writes: begin extract STCKE is notionally closer to TAI than to UTC in that TAI and STCKE are continuous timescales and UTC is discontinous. TAI and STCKE both embody the notion of (micro)seconds since an epoch; UTC is specified in terms of mm dd hh mm ss.fraction with minutes varying in length as leap seconds occur. /end extract Note quite. This formulation is plausible by analogy with the notion that the Gregorian Month of February, normally comprised of 28 days, is comprised of 29 days in leap years. Leap seconds, however, are inserted into UTC by the BIPM upon the recommendation of the IERS (Earth Rotation and Reference Systems Service); and they are conceptually and by definition extracalendrical. Neither 1) the last minute in June or the first minute in July nor 2) the last minute in December or the first minute in the subsequent January is lengthened when a leap second is inserted between them. [This decision was taken advisedly. There are a number of calendars---The Hebrew religious one is the obvious example---that make no use of minutes and/or seconds.] I am not sure how seriously Mr Gilmartin's means his distinction of units is to be taken; cgs [centimeter-gram-second] units and fsf [furlong-stone-fortnight] units are, I suppose, more and less perspicuous; but as long as they are unambiguously interconvertible the choice between them poses only issues of taste not substance. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert historic STCK to local time?
Paul Gilmartin wrote: | By the way, the embolismic day in bissextile years | is February 24, the sixth day before the kalends of March. Yes and no. In some medieval versions of what we call the Julian calendar---It was then called the Roman calendar---February 24th was duplicated; there were two of them cheek by jowl in leap years; and it was not the first February 24th but the the second of them that was the 'embolismic' day. (The Julian leap-year test is the simple one, mod(y,4) = 0. There is no 2nd-order mod(y,400) = 0 for centurial years.) Leap seconds are, among those of us who concern ourselves with these issues, extracalendrical, for the reasons I set out. The NIST feed, which I too have observed, has neither facilities nor time to do things right by inserting, say, 'extracalendrical leap second' into is text. We began on topic, but I think we have already tried the patience of some, and this is my last post in this thread. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
TINC?
I can cite only anecdotal evidence, and people always shout TINC! at me when I say that I suspect the machinations of a CABAL. Moreover, since there are only two of them--A proper cabal should have five members--I don't suppose that the Gilmartin-McKown axis is anything more than a faction. Still, their UNIX-oriented initiatives are a clear danger to legitimate, MVS-based undertakings; and some of the hybrid schemes they have urged are flagrantly subversive of good order. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: TINC?
Not so long ago several efforts to stimulate interest in some useful internet conventions were described/stigmatized as the work a shadowy cabal.. Then, very shortly, responses to such accusations were roputinized too, as There Is No Cabal One etymology--There is a picture of the five of them arranged in a row in the National Portrait Gallery in London--of cabal is Charles [King Charles II] Arlington Buckingham Ashley Lauderdale I promise not to do it again anytime soon John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: TIMEZONE in CFCC
The correctness of the CFCC timezone value may well be unimportant now. I would nevertheless fix it. It may become important at any time. Perhaps more important, its currently irrelevant incorrectness can be problematic anyway. Its lack of what anglophone (and I suspect also Polish) psychologists call face validity will all but certainly lead someone who notes that it is wrong to waste much time eliminating its incorrect value as the source of some other problem. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: TIMEZONE in CFCC
I should perhaps agree if the fix were difficult, but it is trivial. For the reasons I made clear in my earlier post, I would change it. Moreover, it my experience IBM notifications of this sort are not always embodied in personal emails. They may instead be put into planning manuals, where they are easy to miss. Finally, this is of course a judgment call. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Do what to get C strftime %z to work?
CC's LE strictures are understandable, not least because he has done things with it that few others have had the temerity to attempt. As I have said here before: The LE Vendor Interfaces manual is the best reference for knowledgeable people; there is no good reference for novices; and I am not sure that a comprehensive one is possible. The mathematical subroutines are superb; and the dynamic-storage management routines, support for heaps and stacks, are now eminently usable. Some of the other facilities are intrinsically problematic. In the interest of keeping it small, Brian Kernighan's self-abnegating design of C avoids any use of execution-time descriptors, quondam dope vectors; and if you do not know what they are or why anyone would wish to use them you will find them intrusive; COBOL programmers are unused to distinguishing static and LIFO (automatic) storage, etc., etc. To sum up, application programmers need help; but everyone who has set out to help them has found the experience of trying to do so disagreeable. They are a motley crew, and it is hard to meet their very diverse needs concurrently. On 2/22/12, Chris Craddock crashlu...@gmail.com wrote: On Tue, Feb 21, 2012 at 7:01 PM, Charles Mills charl...@mcn.org wrote: Also remember when perusing the LE publications that the inventors of LE in their wisdom thought it would be too clear to the uninitiated to call the languages dependent on Language Environment languages, choosing instead to further overload the word member. And let's not get started on enclaves and all that... it is made easy, for one C function to call another C function What does that have to do with LE? No other platform that I know of has LE, but on every platform cannot a C function trivially call another C function? Otherwise wouldn't every C program have to consist simply of one humongous main()? All high level languages on all platforms have a runtime that provides the magic behind the curtain. Ours happens to be called LE. However, most others are vastly more transparent and obvious than LE - the main point of which was *NOT* so that C functions could call other C functions, but so that multiple varieties of PL/1 and COBOL programs could call each other. Yes folks, that baby really is ugly. LE is old and crufty for lots of reasons and the doc you need to make sense of it is smeared across multiple publications and as myth and legends in the tribal mind. To quote a former president of ours; I feel your pain. Please count this as the 2012 edition of my now long-standing semi-annual rant about LE. I will now retire from the discussion before mortally offending my IBM friends. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: zSeries Manpower Sizing
I think the critical question is How much development of new or significantly extended mainframe systems is going on? Shops that have only low-maintenance, legacy-systems workloads tend to get smaller and smaller over time. On 2/22/12, Hal Merritt hmerr...@jackhenry.com wrote: As others have posted, there are just too many variables to include the nature of the workload and the management strategies. For example, a shop may not accept a job for production if it cannot be managed by exception by the job scheduler. That way, a crew of four can provide 7x24 coverage for thousands of jobs. If manual intervention is allowed, then it might take a crew of 10 or 20 per shift. I do think it is safe to say that a MF shop -can- be much less labor intensive than a comparable server farm. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of George Henke Sent: Thursday, February 16, 2012 5:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: zSeries Manpower Sizing That is not my intent. Please do not divulge anything with which you do not feel comfortable. Where ignorance is bliss, 'tis folly to be wise. Thomas Gray I am just trying to get a sense, a reasonability check, on how labor-intensive a large zSeries shop is. On Thu, Feb 16, 2012 at 6:11 PM, Scott Ford scott_j_f...@yahoo.com wrote: Yep Lizette, and how much money is in the budget ... Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 16, 2012, at 5:21 PM, Lizette Koehler stars...@mindspring.com wrote: I am trying to find out how much staff, numbers and titles, eg z/OS, z/VM, VTAM/TCPIP, CICS, etc, are needed to run a large zSeries mainframe shop. Would some of you be so kind as to share that information with me. -- George Henke (C) 845 401 5614 George the only answer I can give is - It Depends What is the hardware layout, how many mips, SLAs, software mix, external contacts (vendors, business partners), transmission types (NJE, MQ), and so on. You can find titles like z/OS System programmer, z/OS System Administrator, Security officer, Application developers, Network Security, Network Administrators, and so many more. I know of no concise list that would give you information for such a broad question. Could you narrow it down a bit? What is your definition of LARGE. From my vantage point, it is like asking some one what is a tall person. If you are 3ft tall, then 5ft is tall. If you are 6ft tall, then 5ft is small. All is relative. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Do what to get C strftime %z to work?
The heavy irony in the rhetorical question | Why did I think that there might be a clue to the | C/C++ signature CSECT in the C/C++ documentation? is understandable. Moreover, Chris Mason's manner does annoy some people; but it would be unwise to ignore the substantive content of his posts for this reason. Things do not always appear where one would like to find them in IBM publications; and his example is a valuable illustration of how to find them when they do not. Moreover, a good ROT to keep in mind is that things not found in the IBM manuals for a particular statement-level procedural language may well be found in its LE manuals and in particular in the ILC discussions in these LE manuals, which contain useful detail that can be found nowhere else. Moreover again, this is unsurprising. It is easy, because it is made easy, for one C function to call another C function. It s not so easy to induce Java to call C successfully. To do this one needs to know more, and that more is just what is addressed in ILC discussions. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Do what to get C strftime %z to work?
Charles Mills writes: begin snippet What does that have to do with LE? No other platform that I know of has LE, but on every platform cannot a C function trivially call another C function? Otherwise wouldn't every C program have to consist simply of one humongous main()? /end snippet and I concede that I know of no C implementation that supports only 'one humongous main()'; but 1) that was not my point and 2) it is a tendentious, systematically obtuse interpretation of my words. Let me try again. Calling sequences, environments, parameter-passing conventions, and the like differ from one implementation to another of, say, C. Within a single such implementation detailed knowledge of these things is not usually required. It is enough to use correct syntax. When, however, one wishes to communicate from one SLPL to another, things change. One needs to know more about implementation details; things that can and usually do remain implicit in the simpler case must now be made explicit; and for pairs of IBM-supported languages both of which use the Language Environment to do much of their work for them, LE manuals are a good place, often the only place, to find such information. The choice in such situations is between finding and consulting the relevant manuals, whatever they may be called, and reliance upon an afflatus, which may be long in coming. This said, life is short; and I shall not respond again to CM's posts. He can, I am sure, get along very well without my responses; and I can find better things to do with my time. On 2/21/12, Charles Mills charl...@mcn.org wrote: Also remember when perusing the LE publications that the inventors of LE in their wisdom thought it would be too clear to the uninitiated to call the languages dependent on Language Environment languages, choosing instead to further overload the word member. it is made easy, for one C function to call another C function What does that have to do with LE? No other platform that I know of has LE, but on every platform cannot a C function trivially call another C function? Otherwise wouldn't every C program have to consist simply of one humongous main()? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Gilmore Sent: Tuesday, February 21, 2012 4:24 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Do what to get C strftime %z to work? The heavy irony in the rhetorical question | Why did I think that there might be a clue to the C/C++ signature | CSECT in the C/C++ documentation? is understandable. Moreover, Chris Mason's manner does annoy some people; but it would be unwise to ignore the substantive content of his posts for this reason. Things do not always appear where one would like to find them in IBM publications; and his example is a valuable illustration of how to find them when they do not. Moreover, a good ROT to keep in mind is that things not found in the IBM manuals for a particular statement-level procedural language may well be found in its LE manuals and in particular in the ILC discussions in these LE manuals, which contain useful detail that can be found nowhere else. Moreover again, this is unsurprising. It is easy, because it is made easy, for one C function to call another C function. It s not so easy to induce Java to call C successfully. To do this one needs to know more, and that more is just what is addressed in ILC discussions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: was: Abend S0C4 in an internal sort
There may well be a facility for suppressing unwanted DFSORT messages, particularly informational ones. If there is, FY will provide you and the rest of us with information about it here (unless perchance he is in Timbuktu today). John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Batch process VS Started task
Both CICS and IMS have (rather different) facilities for mini-batching, triggering FIFO processing of all of them after an waiting-transactions queue reaches a specified length L 0. This processing threshold L can be varied without making other changes, and doing so provides a mechanism for balancing initialization and transaction-processing path lengths in a way that minimizes their sum. This optimizing machinery is very important , and even if a RYO scheme is used it should be provided. Limiting the design alternatives considered to just 1) batch, all at the same time, or 2) one-at-a-time processing is unwise. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Authorized functions
Learning curves are not culture-free; they are specific to a person and his or her experience. What you find easy and congenial I may find difficult and disagreeable. It is possible to teach able people abstractions that make learning a new instance of some class of formalisms, statement-level programming languages say, easy; but that is another matter. On 2/19/12, zMan zedgarhoo...@gmail.com wrote: On Fri, Feb 17, 2012 at 11:16 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In 1329430553.61141.yahoomail...@web164510.mail.gq1.yahoo.com, on 02/16/2012 at 02:15 PM, Scott Ford scott_j_f...@yahoo.com said: I loved VM/CMS and like Linux really well, close my eyes they are kissing cousins ? I don't see any point of similarity. Not the API, not the file system, not the shells. Then you've forgotten the learning curve: CMS - *IX: minimal CMS - TSO: moderate CMS - GUI: Large -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Archaic allocation in JCL (Was: Physical record size query)
Edward Jaffe has now made the crucial point. Circumventions of any great need to know much about TRK and CYL issues are available (and in one form or another have long been available). That said, the geometry of real DASD was never an intellectually challenging topic; and I grow ever more weary of this and other pleas to spare applications programmers--and often now sysprogs too--any need to know what they are doing and how to do it. I miss any sense of proportion. We were never dealing here with an arbitrary and cruel requirement that intellectually challenged Arsenal footballers master Pali and Prakrit in order to consult their rule books. (Indeed, and to the point, the three Arsenal footballers I have known well were not intellectually challenged.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Archaic allocation in JCL (Was: Physical record size query)
Paul Gilmartin's: begin snippet It would seem to me that when the time came to convert from 3330 to 3350 (e.g.), the simple path would have been to replace TRK with 13030 (CYL slightly more complicated) and leave the other numbers unchanged. JCL so modified would work on either model during the transition, and be suitable for any future DASD. /end snippet is not really wrongheaded. It is an unfortunate oversimplification for real DASD. For them BLKSIZE= values could not be ignored. If they were in moving, for example, from 3350s to 3390s, it was possible, indeed easy, to waste 30+ percent of the new devices' capacity. As I have already had occasion to note today, accurate DASD-capacity calculations parametric in block are not difficult. They require no mastery of---choose the dubious metaphor you find more congenial---either brain surgery or rocket science. Dubious approximations, on the other hand, always gave/give trouble. On 2/17/12, Paul Gilmartin paulgboul...@aim.com wrote: On Fri, 17 Feb 2012 10:39:03 -0600, Mark Zelden wrote: Although it is a crude and inaccurate conversion, one could use M instead of CYL basically 1:1 and would be sure to get enough space since 1M is about 1.42 CYLs. If I did that at least I could picture it in my head the same way I have been doing with with CYL for my entire MF career. On a slightly larger scale, so what if I allocated in M and ended up with 710 CYL instead of 500 CYL. (typical for me to use (500,500) for large-ish allocations). It would seem to me that when the time came to convert from 3330 to 3350 (e.g.), the simple path would have been to replace TRK with 13030 (CYL slightly more complicated) and leave the other numbers unchanged. JCL so modified would work on either model during the transition, and be suitable for any future DASD. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: zSeries Manpower Sizing
'PCI' does not have a single, definitive interpretation. It is yet another overloaded acronym, one that, for sysprogs, often means 'Program-Controlled Interrupt'. On 2/17/12, George Henke gahe...@gmail.com wrote: tyvm, both Radoslaw again and Jihad. I had Wikied it but all I got back was Payment Card Industry, not even Peripheral Component Interconnect. And that did not fit the context, as Radoslaw noted. Maybe you would like to update Wiki. Now all I need to know is how PCI translates into MIPS and MSUs. Maybe if I google LSPR. On Fri, Feb 17, 2012 at 11:04 AM, Jihad Kawkabani jihad_k_kawkab...@progressive.com wrote: PCI - Processor Capacity Index - First calculated/Introduced with the z/OS V1R9 LSPR(Large Systems Performance Reference). -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of George Henke Sent: Friday, February 17, 2012 08:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: zSeries Manpower Sizing tyvm, Timothy, for your expert analysis. Please pardon my ignorance, but what is a PCI? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Archaic allocation in JCL (Was: Physical record size query)
Frank Swabrick wrote: begin snippet | No, I'm not expecting a real answer to that question. | Just trying to point out why it's hard, to say the least, | to know how to size files of this type. /end snippet The question itself has not been very well formulated. No one, I hope and suppose, sizes files directly in cylinders, tracks or megabytes. These are derived quantities. One begins with record types, their individual sizes, and their expected volumes/counts. Initially one has only estimates, often poor ones, of transaction/processing volumes, but these estimates can be improved incrementally by collecting statistics of the volumes actually experienced during processing and then analyzing these data.. That this is not much done does not been that it cannot or should not be done. Adequate capacity planning and even many design decisions are impossible without the systematic collection and analysis of such information. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Entry point on attach
Gerhard has outlined what is available very well, but you seem to be confusing load addresses with entry points and to be assuming that there is/will be only one entry. One, but only one, of the important uses of aliases is to associate different aliases with different entries in the same load module | program object. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Archaic allocation in JCL (Was: Physical record size query)
Frank, Your point is well taken. Often no one has the responsibility. Still, while the system cannot analyze itself, it can include data-collection machinery that greatly facilitates such analyses; and this machinery is/should be the responsibility of those who design and maintain a system --jg On 2/17/12, Frank Swarbrick frank.swarbr...@yahoo.com wrote: But who has the responsibility? This seems something that a system programmer, with some good analysis tools, should do. Or the system itself should be such that it can do it's own analysis. After all, is that not what computers are for? Frank From: John Gilmore johnwgilmore0...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Friday, February 17, 2012 5:21 PM Subject: Re: Archaic allocation in JCL (Was: Physical record size query) Frank Swabrick wrote: begin snippet | No, I'm not expecting a real answer to that question. | Just trying to point out why it's hard, to say the least, | to know how to size files of this type. /end snippet The question itself has not been very well formulated. No one, I hope and suppose, sizes files directly in cylinders, tracks or megabytes. These are derived quantities. One begins with record types, their individual sizes, and their expected volumes/counts. Initially one has only estimates, often poor ones, of transaction/processing volumes, but these estimates can be improved incrementally by collecting statistics of the volumes actually experienced during processing and then analyzing these data.. That this is not much done does not been that it cannot or should not be done. Adequate capacity planning and even many design decisions are impossible without the systematic collection and analysis of such information. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 5 Byte Device Addresses?
Predictably--I am the pedant who insists on distinguishing KB and KiB--Bill Fairchild's point seems to me to be important. Quaint, long familiar terminology should be avoided where it is misleading. The original System/360 scheme was simple and in its way elegant. 01F---decodable unambiguously into (multiplexor) channel 0, control unit 1, and that control unit's device F or 15---was, for example, the usual device address of the card punch circa 1965, when punches were still real rather than virtual devices. Whatever its historical interest may be, this scheme and its progressively less elegant, patched together successors are now architecturally irrelevant; and it is time to 1) give the old terminology a decent burial and 2) talk about device numbers instead. On 2/16/12, R.S. r.skoru...@bremultibank.com.pl wrote: W dniu 2012-02-16 15:14, Bill Fairchild pisze: They haven't been device addresses since 1983 with the advent of MVS/XA, in spite of the fact that people who had been calling them device addresses since 1964, for the most part, still call them device addresses. They have been device numbers since XA's redesign of the I/O architecture. And developers and documenters still create screen displays and tech doc with the now 31-years-obsolete nomenclature. I complain now and then to deaf ears. But that's ok, since I still call z/OS by the name MVS. At least I don't still call it OS/VS2 Release 2. Lol Yes, in z/OS (OS/390,...) there are device numbers, not adresses. Device numbers replaced device addresses in some sense (like VARY command, etc.). However people still use device address in place of device number. We discussed about fifth byte of the device number, and nobody was harmed by usage of device address. Everyone knew what are we talking about. IMHO that's the most important. Similar problems: KiB vs kB (1024 vs 1000) Unix System Services vs USS Radoslaw Skorupka Lodz, Poland tej wiadomo ci mo e zawiera informacje prawnie chronione Banku przeznaczone wy cznie do u ytku s bowego adresata. Odbiorc e by jedynie jej adresat z wy czeniem dost pu os b trzecich. Je eli nie jeste adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie zabronione i mo e by karalne. Je eli otrzyma wiadomo omy kowo, prosimy niezw ocznie zawiadomi nadawc wysy c odpowied oraz trwale usun wiadomo czaj c w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl d Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru S dowego, nr rejestru przedsi biorc w KRS 025237, NIP: 526-021-50-88. ug stanu na dzie 01.01.2012 r. kapita zak adowy BRE Banku SA (w ca ci wp acony) wynosi 168.410.984 z otych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Alfred, Lord Tennyson, speaks on MS-Windows
I'm not at all sure that I want to rub off on anyone.
Mr Tuco's quotation is apposite, although what Macbeth had in mind was
the totality of human experience, which is the sense in which Faulkner
cribbed the same text for his title.
The Tennyson pastiche is another matter. The original version of The
Wasteland contained a somewhat more extended Pope pastiche written in
heroic couplets. Eliot asked Pound what he thought of it; and Pound
said, 'Take it out. It would work only if you could write better
lines than Pope, and you cannot'.
On 2/15/12, Bonno, Tuco t...@cio.sc.gov wrote:
Careful! Gilmore is rubbing off on you. :-)
= oh no, oh no; believe me, I come by that quite naturally on my own,
w/o any need for mentoring ...
/s/ tuco
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Bonno, Tuco
Sent: Wednesday, February 15, 2012 10:00 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Alfred, Lord Tennyson, speaks on MS-Windows
macbeth, imo, says it even better
but a walking shadow, a poor player That struts and frets his hour
upon the stage And then is heard no more: it is a tale Told by an idiot,
full of sound and fury, Signifying nothing.
/s/ tuco bonno;
Graduate, College of Conflict Management; University of SouthEast Asia; I
partied on the Ho Chi Minh Trail - tiến lên !!
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of McKown, John
Sent: Wednesday, 15 February, 2012 10:43 AM
To: IBM-MAIN@bama.ua.edu
Subject: Alfred, Lord Tennyson, speaks on MS-Windows
Our little systems have their day; They have their day and cease to be; They
are but broken lights of thee. -- Tennyson
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. HealthMarkets(r) is the brand name for products underwritten and
issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake
Life Insurance Company(r), Mid-West National Life Insurance Company of
TennesseeSM and The MEGA Life and Health Insurance Company.SM
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@bama.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
--
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBM Doing Some Restructuring?
Dave Day's comment begin snippet The idea of hiring temporary workers, the 'liquid' people referred to in the article, seems to me to be at odds with long term, successful growth. IBM is adopting Walmart's business model on this one. /end snippet is, as the MBAs would surely say, 'insightful'. Moreover, it suggests to me that successful growth can be defined in many different ways. I suspect that IBM is in fact adopting Apple's business model: Design it using a small number of highly talented people in one place; then implement/manufacture it quickly using 'liquid' because currently unemployed people elsewhere, in China or, shortly, a successor low-cost location that does not yet have a safety net for the poor in place. On 2/13/12, Veilleux, Jon L veilleu...@aetna.com wrote: I think that this paragraph is interesting: We were previously using configuration management version control, which required a lengthy code check-in process, said Clark Dudek, software developer, IBM Systems and Technology Group. Rational Team Concert has encouraged greater code collaboration and better work item tracking within my team. I guess IBM doesn't think they need version control anymore. Might that be why we are seeing more problems lately? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Dave Day Sent: Saturday, February 11, 2012 11:31 AM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM Doing Some Restructuring? Well, hindsight being 20-20, it is obvious management within IBM has done both some incredibly smart, and incredibly dumb moves over the past 30 yrs. or so. I know every time I applied for a job, I always wanted to work on a part time basis, because I just didn't want that feeling of security everyone has to some degree when they take permanent full-time employment. And every time I have worked on a part time job, when an offer came along for a full time position, I always turned it down. Mostly because I felt loyalty to the current employer for offering me the part-time, temporary position instead of making me take full-time employment. And for sure, we all know software development is much easier when you don't have the previous developers around to just clutter things up when you are spending all that time going thru the code to try to figure out why this or that function is coded the way it is. The idea of hiring temporary workers, the 'liquid' people referred to in the article, seems to me to be at odds with long term, successful growth. IBM is adopting Walmart's business model on this one. --Dave On 2/11/2012 10:06 AM, Edward Jaffe wrote: http://socialbarrel.com/ibm-job-cuts-in-germany-8000-may-be-laid-off/3 1574/ Rumor has it that IBM is laying off up to 40% of its workforce in Germany. At the same time they are testing a new global temporary worker program that they believe can speed up project implementation by 30% and reduce costs by 1/3. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBM Doing Some Restructuring?
For now it is likely that some of the non-mainframe configuration-management schemes are more flexible, because less bureaucracy-encrusted than the schemes we are accustomed to using. The Anglican Communion's Book of Common Prayer has this to say about problems of this sort, which are ineluctable: There was never any thing by the wit of man so well devised, or so sure established, which in continuance of time hath not been corrupted. New initiatives need to be criticized in their own terms, and they often need it badly; but reflexive defense of and retreat into the familiar is rarely helpful. On 2/13/12, Anne Lynn Wheeler l...@garlic.com wrote: arthur.gutow...@compuware.com (Art Gutowski) writes: Patterned after centuries (millenia?) of cultural character - raze the conquered and build your empire on the remains. re: http://www.garlic.com/~lynn/2012b.html#74 IBM Doing Some Restructuring? http://www.garlic.com/~lynn/2012b.html#76 IBM Doing Some Restructuring? I had sponsored Boyd's briefings at IBM in the 80s ... and he had a very interesting scenario for this. some Boyd URLs from around the web as well as past posts http://www.garlic.com/~lynn/subboyd.html Part of his briefings was that at the entry to WW2, the Army had to deploy a huge forces with little or no experience. To leverage the small amount of skilled/experienced resources they created a rigid, top-down command and control structure. He would then observe that this was then starting to have a significant downside on US corporate culture ... as former young WW2 officers, skilled in rigid, top-down commandcontrol structures were started to climb corporate ladders. They were beginning to implement similar infrastructures that assumed only the very few at the very top knew what they were doing and required rigid controls for large hordes that didn't know what they were doing. Something similar was touched on in Tandem Memos (even before I met Boyd) ... from IBM Jargon Tandem Memos - n. Something constructive but hard to control; a fresh of breath air (sic). That's another Tandem Memos. A phrase to worry middle management. It refers to the computer-based conference (widely distributed in 1981) in which many technical personnel expressed dissatisfaction with the tools available to them at that time, and also constructively criticised the way products were are developed. The memos are required reading for anyone with a serious interest in quality products. If you have not seen the memos, try reading the November 1981 Datamation summary. ... snip ... I had been blamed for online computer conferencing on the internal network in the late 70s early 80s (part of which was Tandem Memos) ... misc. past posts mentioning the internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet part of the folklore was that when the executive committee was informed of online computer conferencing (and the internal network), 5of6 wanted to fire me. Boyd's explanation has been used more recently to explain a report that the ratio of executive compensation to employee compensation had exploded to 400:1 (Age of Greed, mentioned in earlier post, claims it spiked over 500:1), after having been 20:1 for a long time and 10:1 for most of the rest of the world. The other downside is that people at the bottom that may appear to know what they are doing, can be viewed as a threat. other recent posts mentioning Age of Greed: http://www.garlic.com/~lynn/2012b.html#12 Sun Tzu, Boyd, strategy and extensions of same http://www.garlic.com/~lynn/2012b.html#19 Buffett Tax and truth in numbers http://www.garlic.com/~lynn/2012b.html#29 The speeds of thought, complexities of problems http://www.garlic.com/~lynn/2012b.html#43 Where are all the old tech workers? http://www.garlic.com/~lynn/2012b.html#54 The New Age Bounty Hunger -- Showdown at the SEC Corral -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why can't the track format be changed?
Minimally, modus ponens yields the result that the production of real CKD devices did not end before the production of real 3390s--which were/are real CKD devices--ended. On 2/8/12, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: I think when manufacturing real 3390 devices ended. Kees. Bill Fairchild bfairch...@rocketsoftware.com wrote in message news:77142D37C0C3C34DA0D7B1DA7D7CA346AE5C@nwt-s-mbx1.rocketsoftware .com... When did the manufacturing of real CKD devices end? Bill Fairchild -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Anne Lynn Wheeler Sent: Tuesday, February 07, 2012 6:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Why can't the track format be changed? it wasn't too long before real CKD were no longer manufactured ... CKD becoming an obsolete technology simulated on real FBA. various past posts on the subject http://www.garlic.com/~lynn/submain.html#dasd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: C program and LE/IMS option
Eliminating LE usage from a [non-Metal] C function would be a formidable undertaking. You can, however, set up the LE before the first CALL to your C function and keep it up between these CALLs in such a way that you incur the setup overhead only once. As is often the case, the LE Vendor Interfaces manual contains relevant information even for non-vendors. On 2/3/12, ITURIEL DO NASCIMENTO NETO 4254.itur...@bradesco.com.br wrote: I think you can use Metal C. Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto BANCO BRADESCO S.A. 4254 / DPCD Engenharia de Software Sistemas Operacionais Mainframes Tel: +55 11 4197-2021 R: 22021 Fax: +55 11 4197-2814 -Mensagem original- De: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] Em nome de Itschak Mugzach Enviada em: sexta-feira, 3 de fevereiro de 2012 09:05 Para: IBM-MAIN@bama.ua.edu Assunto: C program and LE/IMS option I have a C program that is called intensively more then 10 times per second. As it runs under LE, it requires LE to re-create the language execution environment which is a huge overhead for a small and short running program. I want to eliminate LE to get involved. I thought that static bind will cause the LE stub program to branch instead of load q link to LE callable services. What should i do, compiler wise in order to eliminate LE to interfere? the compiler option TARGET(IMS,CURRENT) instead of (TARGET(LE,CURRENT) may help, but there is no IMS involved and I can't expect the results (I ma not the one who compiles the program). I hop I explained my problem ... Will be happy to get your advice on this. ITschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN AVISO LEGAL br...Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. LEGAL ADVICEbr...This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: C program and LE/IMS option
I am delighted to learn that SPC is alive and apparently not even moribund. The LE tends to be deprecated here, particularly by those who have not used it enough to master it; but in my own view its storage-management and condition-handling facilties are redemptive; and what I have learned here about how RYO circular functions and the like are often implemented has made me very suspicious of library-avoidance schemes. The overhead of establishing any supportive environment is horrendous when it is set up and torn down around single subroutine calls; that is a mug's game; but, as I and others have tried to make clear, it is a game that need not be played with the z/OS LE. On 2/3/12, Tony Harminc t...@harminc.net wrote: On 3 February 2012 08:11, John Gilmore johnwgilmore0...@gmail.com wrote: Eliminating LE usage from a [non-Metal] C function would be a formidable undertaking. You can, however, set up the LE before the first CALL to your C function and keep it up between these CALLs in such a way that you incur the setup overhead only once. There is a third option: System Programming C, which provides a sort of LE-lite facility. As the book (the Programming Guide) says, System programming facilities enable you to run applications without z/OS Language Environment or with just the z/OS XL C library functions available. You can: Use a subset of the C language to develop specialized applications that do not require z/OS Language Environment on the machines where the application will run. You can write freestanding applications that: Do not use the dynamic run-time library. Use only the C-specific library functions without any z/OS Language Environment facilities to manage the execution environment. In many cases converting an existing LE-using program to use the SPC facilities is straightforward; in others near impossible. And take note that there is no SPC++. SPC predates Metal C by many years, and its focus is a little different. One nonetheless suspects that SPC will be deprecated at some point, but to my knowledge that time has not arrived. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STCKF availability
See page 1-14 of the current PrOp, which specifies that the 'Store Clock Fast Facility' became available in September 2006. On 2/3/12, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Fri, 3 Feb 2012 14:39:35 -0600, Anthony Fletcher wrote: Does anyone know which machine the STCKF instruction became available on?. z9, IIRC -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Returning to the fold
A fold is an enclosure for sheep. Fold is also the terms of venery for sheep, as in a fold of sheep, a pride of lions, a pod of whales, a pile of proctologists. By extension the/a fold now often means a set of people or, less commonly, organizations that share some preoccupation or prejudice. On 2/2/12, Mike Schwab mike.a.sch...@gmail.com wrote: Which also figures into the name of the Star Trek Original Series Episode http://en.wikipedia.org/wiki/Wolf_in_the_Fold On Thu, Feb 2, 2012 at 2:25 PM, Farley, Peter x23353 peter.far...@broadridge.com wrote: Sheep fold. The lost sheep returns to the fold to join the flock. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM As I am always interested in special/local/slang/etc. variations of English: what is 'the fold'? -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: What precompiler/compiler options are required to have a PLI program dynamically call DSNHLI?
Check out the DLLINIT compiler option, and be aware that PL/I has a FETCH statement. Much that is implicit in other SLPLs can be explicit in PL/I. On 2/2/12, Binyamin Dissen bdis...@dissensoftware.com wrote: In COBOL, the DYNAM compiler option will do the job. ASM, a DSNHLI stub. How about PLI? I don't see an obvious option that causes CALL to do a LINK (or CEELOAD) in place of a statically linked subroutine. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: TOD clock format
Gerhard Postpischil wrote: | And Toronto will be a U.S. city? G I was reliably informed that 'Toronto' has for some reason always been problematic; a precursor of Watson, reasoning by phonetic analogy with 'Taranto', moved it to Italy in a slightly different context. --jg On 1/31/12, Gerhard Postpischil gerh...@valley.net wrote: On 1/31/2012 3:48 PM, Ken Porowski wrote: Watson should be answering all the questions by then . And Toronto will be a U.S. city? G Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Hands up! (Was: CPP (C++) file on z/OS)
I relish Chris Mason's posts. There are an unconscionable number of [to the rest of the world obscure] Americanisms used here without thought, and Chris gets his own back by using what are to many Americans equally obscure Briticisms. How many of the Americans here can recite on the curate's egg or the Agincourt salute without googling one or both of them first? John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
