Re: Early IPL problems
On 5/23/2012 10:17 AM, Shmuel Metz (Seymour J.) wrote: You also used this to reply to password requests for system data sets having all hex-zero passwords. I don't recall[1] having done so. If you can explain How I forgot, I'd like to try the same technique on some other, equally undesirable, memories. You used the PASSWORD facility to protect critical data sets. In order to update them, it was necessary to respond to a WTOR with the password. The password was all hex zeroes, and could not be entered from a conventional console. You switched to the 00C/00E alternate console, and feed in a Reply nn card with the hex zeroes multi-punched [1]. That was inconvenient enough so that I wrote SETPASS [2]. [1] These days the method may be less safe, with some tn3270 clients offering keyboard customization including hex values. [2] That was a great learning experience. I had hard-coded the number of block per track in the PASSWORD data set, and at some point (OS/360 15/16, or 18?), IBM decided to change the device related constants and the PASSWORD data set wound up with one block less per track. 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
Re: Early IPL problems
On 5/21/2012 8:13 AM, Shmuel Metz (Seymour J.) wrote: While it was popssible to use a card reader and printer as a console, and to use a printer as a hardcopy console, that was not something that I did except under duress, e.g., for diagnosing JES2 parameter errors. You also used this to reply to password requests for system data sets having all hex-zero passwords. If that was duress, it was self-inflicted 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
Re: CSVEDIT using COBOL
On 5/14/2012 12:50 PM, Mansi Kulkarni wrote: Sir, In IEBEDIT utility of JCL Statement //SYSUT2 DD SYSOUT=(*,INTRDR) is used. Ok. In this Plz explain why used * here, if we write any character there then also program run. What is * her? I thing it is for priority like we used class in job statement. Am i write? No. Traditionally SYSOUT was a single character in the range A-Z and 0-9. Several decades ago IBM added * top copy the MSGCLASS as the SYSOUT class. However, for INTRDR the class is ignored. Try to use google to have your basic questions answered. 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
Re: iggcsirx to retreive data set size?
On 5/9/2012 9:29 AM, Victor Zhang wrote: Can I use iggcsirx to retrieve dataset size like listdsi does? Is there any example? CSI only returns catalog information. So non-VSAM data sets won't give you anything useful, but you could do a LISTDSI on each retrieved one, preferably not for migrated ones. 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
Re: EXTRACT,QEDIT macro
On 4/23/2012 5:30 PM, Micheal Butz wrote: If after issuing the EXTRACT to get the address of the communication parameter list (com) and the communication input buffer (cib) I attach 4 subtasks are the com/cib address obtaining by the originating tasks valid for the subtask that I have now attached The CIB is one element in a chain of 0 to a maximum count, depending on how you initialized processing. I usually set the maximum to 1 because that makes the logic a little simpler. When your program starts, there may or may not be a START CIB. You should see one in an STC, but not usually when running under an initiator. After you set the maximum CIB count to non-zero, the CommECB is posted when a STOP or MODify adds a CIB to the chain. After you process that CIB, you would normally free it. Once you understand the processing, the QEDIT description should make more sense. Also note that a STOP command posts the ECB with an X'50', whereas all others post with X'40'. 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
Re: GO TO "cobol"
On 4/16/2012 1:35 PM, John Gilmore wrote: 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. The comma is a result of a personal(?) idiosyncrasy. Since the late sixties, I have used columns 65-71 to indicate code changes (author,date); this practice permits detailed identification of modifications that may not be as obvious when provided as paragraph or program comments. Omitting the comma results in assembly errors. 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
Re: GO TO "cobol"
On 4/16/2012 12:26 PM, John Gilmore wrote: 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 | . . . "Must" you? In this case I would prefer: .* &i seta0 *default* .trvloop aif(&i ge n'&array).trvend &i seta&i+1 . . . ago .trvloop .trvend anop, That's six statements instead of nine. I was raised in the era of six (ForTran) and eight character variables, and find those easier to read. I'd use &ne only for larger array sizes; for small ones the savings are not noticeable. Whether or not code is aesthetically pleasing is very much a matter of nurture. With effective comments, the structure of code isn't all that critical, and discussions of GOTO versus GOTO-less programming are about as useful as religious arguments. 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
Re: LE C calling HLASM
On 4/6/2012 7:23 PM, Ken Brick wrote: many years ago I needed to know, in DOS/VS, whether an assembler routine was called from a PL/I or assembler module. I put in a test to see if in DOS terms the weak extrn PLIMAIN was not 0. Non zero meant a PL/I module was present. This works for special cases, but not in general. For instance, consider a PL/I program calling ASM calling CoBOL calling ASM. The second ASM would incorrectly conclude it was called from PL/I. I ran into an analog of this trying to determine whether a program is running under TSO - presence of TSO control blocks does not indicate that the immediate caller was the TMP. IBM, for whatever reason, disallowed multiple TMP invocation in MVS (or perhaps SVS?), so these days one can just rely on the result from EXTRACT. 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
Re: Malicious Software Protection
On 3/27/2012 7:27 PM, Ray Overby wrote: Like any SVC when invoked it will get control in an authorized state (PSW Key 0). Further this SVC issues a STM instruction very early in the SVC code storing into where ever R13 points to. This type of defect is easily exploited writing a simple program (could have been posted on the web) that would issue the SVC and: Defect is the correct description; your SVC sounds as though written by an incompetent programmer. User's registers are preserved in the RB (PRB, SVRB), where they are protected, rather than the save area. Off-hand I can't recall any SVC that needs R13 to point to a save area, rather there are cases where R13 is destroyed. 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
Re: PCOM Question (IBM Personal Communcations aka 3270)
On 3/21/2012 8:38 AM, Chris Mason wrote: Since the "Wizard of Lodz" is so keen on directing the list manager to perceived - and certainly in one case totally invented - malpractice on the behalf of other list contributors[1], I would like to propose that it is a "hand-on-heart" rule that any poster promoting a commercial product[2] should declare any pecuniary interest. While I fully concur with your intent, the practice might make that a bit difficult. Generally I find out what I have a pecuniary interest in only after I receive and review monthly statements from my trust company, who switch investments based on their computer projections with no input from me. Additionally, many holdings are mutual funds, and finding their holdings can be quite time consuming, and generally not worthwhile. I would hope that many other contributors are in a similar situation with 401k plans. The best we can hope for is for posters to reveal their known previously Undisclosed, Secret Support (USS) payments. 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
Re: IEFBR14
On 3/18/2012 1:29 PM, Paul Gilmartin wrote: When you use the ALLDATA option, DSS copies whatever exists past the last valid EOF. ... Presumably also past DS1LSTAR? I didn't want to write a novel. When I make permanent backups with DSS, I normally use ALLEXCP; that way a clobbered LSTAR doesn't prevent recovery of data. I've never had the joy of setting up HSM, nor copying empty PDSs with DSS, so can't attest to early performance. But I would find it surprising if they failed. In my experience, stupid mistakes aside, IBM tends to produce slow, but thorough utility code (with modern SORT the exception, perhaps due to market pressure, and the outstanding quality of the support team). 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
Re: WTOR problem
On 3/19/2012 8:45 AM, Micheal Butz wrote: I am having problems with following coding generating a re-entrable version of the WTOR below is the relvant code WTOR TEXT=(D_MSG,REPLYAREA,REPLY_LEN,REPLY_ECB),MF=(E,WTO_D_L When you are dealing with old macros, use a PRINT ON,GEN around them, inspect which fields they set, and artificially fill in the missing pieces. Alternatively, use two MF=L forms, one in a CSECT and one in your DSECT, and copy the CSECT instance to the DSECT one. In general, that will allow the MF=E form to build a complete parm list. 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
Re: IEFBR14
On 3/18/2012 9:03 AM, Ron Hawkins wrote: And finally, my memory may be a bit dodgy nowadays, but it's my recollection that the EOF for empty datasets was introduced so that DFSMShsm and DFSMSdss could migrate, move and copy empty datasets. When there is no EOF for a zero empty dataset these utilities choke and spit it back. I don't think security was an objective. When you use the ALLDATA option, DSS copies whatever exists past the last valid EOF. This means that it has the capability of copying anything, regardless of DCB parameters, or whether or not those tracks have been used. So exactly what condition would "choke and spit it back"? I guess that DSS, and presumably HSM, use a Read Track or Read Track Multiple, and the only condition that might cause a problem would be an uninitialized track, lacking basic home address information. 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
Re: IEFBR14
On 3/13/2012 10:52 AM, Paul Gilmartin wrote: Why should this peculiarly affect IEFBR14? (Although, to be fair, Gerhard never denied that it affected all programs.) Given enough dd statements, on a slow processor, it will take enough time to exceed a small standard time limit. Wouldn't a better solution than a specialized IEFUTL be to increase the standard time limit, at least enough to accommodate IEFBR14? The jobs in question were running at a service bureau, thus we could not just arbitrarily change user's time specifications; while we imposed limits by job class, we did not supply defaults. In general, JOB statements did not have TIME parameters, and I've never seen an IEFBR14 step with a TIME value. The system initiator scheduled the IEFBR14 step with the requested time, 0, and I found it more interesting that this ever worked. Since we already had an IEFUTL (to remind operators of unhandled tape mounts, etc., and to grant extensions to special jobs), adding a quick test for IEFBR14, and granting a minimal extension, was trivial. AFAIK, IBM addressed the problem by using a non-zero TIME to dispatch an IEFBR14 step. 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
Re: IEFBR14
On 3/13/2012 3:46 AM, J R wrote: Just to be clear, IEFBR14 has no functionality per se. It's hard to imagine circumstances where it would not or could not execute correctly. IEFBR14 seems to start a regular thread every year. However, there is one case that I have not seen mentioned - in the dark ages, under release 21 of OS/360(MVT), IEFBR14 steps on our system abended with S322. I had to write a special exception into IEFUTL to allow allocation to complete. 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
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/11/2012 9:07 AM, John Gilmore wrote: 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. I cringe at the word "production" - purportedly (google search came up empty) not too long ago in our nation's history it was common practice to paint sparrows for the purpose of selling them as parakeets. While I don't recall a proposition on swans, I was reminded of the Pejorative Calculus (Joel Cohen, "On The Nature Of Mathematical Proofs", The Worm-Runner's Digest, Vol. III, No.3, December 1961), where Lemma I (all horses are the same color) is credited to Professor Lee M. Sonneborn, then at U. of Kansas. 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
Re: TINC?
On 3/5/2012 10:06 AM, Gross, Randall [GCG-PFS] wrote: I worked one summer for a company that had a 256k 360/40 running MFT with (typically) 4 partitions. Iirc, it took an IPL to reconfigure MFT. (M = multimple, F = fixed) If your installation required an IPL, then I surmise it either had an alternate nucleus that was smaller, or that the staff weren't trained properly (note earlier post on redefining partitions). We ran MFT at ADR for a couple of years, and I remember redefining partitions, but never had to IPL to do so. 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
Re: Customer Service, the good and the bad...
On 3/3/2012 3:16 AM, Robert Prins wrote: Needlessly to say, when I bought a new PC for myself at the beginning of this year, and a new notebook for my wife, I stayed away as far as possible from HP. I don't know if my experience was an exception, but even if it was, that is no way to treat your customers! Back in 2004 I purchased a Compaq laptop that included a rebate for either cash or software. Also they had a "deal" on a memory stick with a rebate. They refused both rebates on the grounds that I didn't send them in in a timely fashion (within 45 days of purchase!). While I kept and used the laptop until it gave up the ghost, I replaced all my HP printers with Kyocera, with cheaper and better features, and sleep soundly that they lost more on toner sales than the rebates would have cost them. 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
Re: Batch process VS Started task
On 2/19/2012 4:25 PM, Magen Margalit wrote: We have a daily betch job that is processing as input records which has been collected all day. volume of records is about 5 millions for 24 hours. With allowance for growth, you're looking at 100-200 records per second, and that's well within the capacity of modern equipment. Depending on how the records are created, you have overhead for serialization and backup (do you need an audit trail to recreate records if the file is lost?). You would need to do some testing to see whether the serialization and processing overhead for live processing is tolerable, since the batch presumably offers some savings in overhead. If the records are created by a single source, then instead of an STC program, you could consider a subtask, a PC routine, or (gasp) even a user SVC. For multiple tasks, either an SVC or a PC routine might do. The preferred method depends on how the data are created, how they are placed into the batch input file, and what processing they are used for. In order to make systems more "online" we are looking for a way to run the process for each record all day long instead of a daily run, and doing so with minimum as possible application changes. If you have a PUT, WRITE, or similar function to create the record, it's easy enough to replace that with a PC or SVC call. But you will need to develop contingency plans for data sets becoming full, or other occurrences that could prevent live updating. One idea that came up is to convert the process to a "self developed" STC which will be triggered by a record on an MQ queue and will run as STC all the batch process programs To me it seems like a bad idea because having a "self developed" STC in production create a maintenance gap (and where there is one STC a second one will soon to follow...)... When I worked at ADR in the sixties, we developed our own data collection and accounting routine long before IBM offered SMF. We had our own tape library software long before UCC-1 (or TLS). We had our own security software long before RACF (in addition we used IBM passwords, but only for critical and SYS1 data sets). In each case the staff contained more than one person familiar with the software and the ability to maintain it. While IBM is trying to make the system more accessible (i.e., dumbed down) your installation should have enough staff familiar with internals to write and maintain the code. Basically you need whatever the batch process is doing, and add provision for backup and serialization. Of course it's always possible to overcomplicate things to the point where nobody can maintain it. 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
Re: Authorized functions
On 2/19/2012 5:38 PM, zMan wrote: Point taken. But vastly dissimilar environments are pretty likely to have greater learning curves than moderately similar ones, nu? Not necessarily. Sometimes it's the similarities that trip you up. 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
Re: Entry point on attach
On 2/17/2012 5:21 PM, Micheal Butz wrote: Again if I do a attach with disp=no And r1 has the tcb address I can look at the TCBRBP or relating CDE for the loadpoint of the module I'm not really sure what you're looking for. The CDE (or LPDE for an LPA module) points to another CDE (if it's an alias, a.k.a. minor entry), or an extent list. The CDE has the entry address, the XT list the load address and size. If you are asking about an additional entry in the program, then ATTACH will find that only if it's an ALIAS entry in the load library. If it's not an ALIAS, and you have made some provision for finding the entry address programmatically, you can load the module before the ATTACH, and use IDENTIFY to create a name for the entry. The IDENTIFY method may also be used to let you load the program prior to the ATTACH, so that you know the address, and attach with the fake name. 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
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
On 2/14/2012 9:42 AM, Thomas Berg wrote: AFAICS, what needs to be changed is just the interpretation of the SPACE parm and the actual allocation on disk at the time of execution. -> There have been changes in the JCL "language" the latest Years: LIKE, DCB subparms outside of the DCB parm, etc. This could obviously be done. -> There can't be that many places that does the allocation of the space on disk. Note that there is no change of cataloging as such, just the process of adding/extending the extents as the dataset is expanding. There is no need to change the old code more than allowing a "branch" to the new code to handle the case of the new variant of the SPACE parm. You may think of your request as being reasonable, but a new SPACE parameter could be added in less time than this thread has been going. There is no one place where old code can be branched away from, rather space/extent processing is endemic in all DASD related code. More critically, most I/O related control blocks have physical limits, and would require major redesign to handle even static expansion, not to mention dynamic. By comparison, supporting FBA devices in zOS would have been trivial, but IBM could not justify that, either. 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
Re: EXTRACT FIELDS=COMM for subtasks
On 2/10/2012 4:34 PM, Micheal Butz wrote: I know EXTRACT FIELDS=COMM (using the ECB) for stop or modify command works for the TCB your running dunning the course of my programming I attach 4 other subtasks is there any parameter on the ATTACH e.g. like ALCOPY( work for access lists) where I can share COMECBPT among subtasks The CSCB and CIBs are tied to the address space, not a particular TCB. An ECB may be waited on by only one task at a time, so can't be "shared." Depending on what you need, it might make more sense to establish a subroutine in your main task that posts your subtasks and routes the CIB text as necessary. 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
Re: TOD clock format
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? 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
Re: AutoCoder
On 1/17/2012 6:22 PM, Roberts, John J wrote: Also, is it PL/1 or PL/I? My mainframe IBM manuals use PL/I. The early version(s) of the S/360 compilers were inefficient by not using available hardware instructions, e.g., bit fiddling doable with OI and NI was implemented as subroutine calls. And similar to ForTran, each load module included almost the whole subroutine library, thus wasting (then) valuable memory. 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
Re: Error apply ZAP
On 1/7/2012 2:31 PM, Ed Gould wrote: constant zap issue. I can't remember of ever having the issue with IBM as they send out module replacement (thanks!) I feel its important to maintain the IDR to find out what level the module is at. With the vendor I spoke of it was somewhat of an issue at times. That is why I am a strong supporter of module replacement and zaps are for emergency fixes only. I've had the issue with IBM modules a long, long time ago. Assuming ZAPs are sequential, I prefer putting an identifier, APAR or whatever, into the eyeball text at the beginning of the module. That way I can see in a dump how it's been updated, rather than having to run a report. Module replacements take more effort and disk space, so ZAPs are closer to being green 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
Re: Semiprivileged instructions, part 1
On 12/29/2011 8:57 AM, Peter Relson wrote: z/OS itself does not provide support for TRAP2/TRAP4. But some (authorized) program products do this on their own (a bad decision not to have this provided by the operating system). ... The long and short of it is that you can't use TRAP2/TRAP4 "on your own" if you are not privileged. These are the two instructions I love to hate. Life would be a lot simpler had they be implemented as No-Ops unless trapping was enabled. Some years ago I was assigned to debug an LPA resident program that had mysterious, intermittent failures, but always worked while being tested. Because the failure modes differed (e.g., bad data rather than an interrupt), SLIP was of limited utility. Had there been a benign form of TRAP (ignored by other tasks) it would have been a lot easier to track this (turned out to be an uninitialized variable). 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
Re: Imagine having to deal with THIS in production
On 12/21/2011 2:18 PM, Chase, John wrote: Already been tried: IBM-MAIN-OT in Yahoo Groups. Can you say "lead balloon"? I guess you missed the Mythbusters episode where they obtained lead foil, inflated it, and launched it And a better name for the group would be DRIFT-WOULD? 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
Re: Imagine dealing with THIS in production
On 12/19/2011 4:17 AM, glen herrmannsfeldt wrote: But if I understand it right, the date is computed from the value in the interval timer, along with various offsets, only when it is actually needed. Nothing special actually happens at midnight on Dec. 31st. Which is not how I remember it. The interval timer is set to pop at midnight, and that updates CVTDATE appropriately. I do recall an admonition that near midnight to use SVC 11 for the date, rather than CVTDATE, to get a synchronized value, as there was some latency in the date update. 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
Re: Is there an SPF setting to turn CAPS ON like keyboard key?
On 12/16/2011 1:06 PM, Phil Smith wrote: OK, trivia time: What IBM device had *13* PF keys? Not what you wanted, but on my 3277 I wrote a game that treated Test-Request as PFK 0. 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
Re: JCL "sheesh!" for today
On 12/10/2011 1:19 AM, Ed Gould wrote: A parm on the exec card in order to be continued had different rules and IIRC must start in CC 16 *AND* cannot be any longer than 100 characters (thats a double restriction) *AND* must have a continuation in 72 (thats three) which IIRC there is no other DD parameter has any restrictions (that I can remember of). That hasn't been true for ages. A PARM in parentheses may be continued over multiple records, and may start in columns 4-16. Only the 100 character restriction still applies. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to read past EOF
On 12/9/2011 12:46 PM, Skip Robinson wrote: I have a GTF trace file full of gold nuggets and bright red rubies. Unfortunately GTF trace was restarted at the next IPL, so the data set has immediate EOF. I used StarTool to reset logical (VTOC) end of file to the full extent. Anyone know how to bypass physical EOF and read/copy from block 2 all the way to the end? If it has an EOF, then presumably the rest of the track has been erased. You should be able to recover the rest by using BSAM to copy the file, but issue a POINT immediately after OPEN. If you have the ability to ZAP the VTOC entry, and nobody else is using the volume, just zap the DSCB1 start extent up one track, do a normal copy (IEBGENER, or whatever), then zap it back. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Licence to kill -9
On 11/29/2011 9:16 AM, Don Imbriale wrote: The manuals should be the first place to go. Google can be useful, but should be used only after using the manuals. The message or other symptoms, when used as a search argument, may not reveal anything. This is not an indication that you have encountered a new problem that no one else has found, and therefore automatically post to IBM-Main or other support mechanisms for an answer. While I agree with you in principle, the practice is somewhat wanting. In the past I've found information in the printed manuals that was not available in digital form; the first time I ran into this I was doing maintenance at an ISV. The program allocated a temporary SYSIN data set, wrote one line, closed it, allocated a temporary SYSPRINT, and attached IDCAMS, then opened SYSPRINT, processed the file, then closed and freed the temporary files. I suspected that there was a better way, but couldn't find it - there were some elusive hints to a figure, but that didn't show up. It was only when I tracked down the printed version that I found all necessary information in the illustration - setting up a SYSIN/SYSPRINT exit to avoid the allocation and de-allocation of files. I suspect that the situation wasn't unique to the IDCAMS documentation, but it was the first I found where all the needed information (return values, PARM format, etc.) appeared only in an illustration. The situation with messages isn't straight-forward either. It takes lots of time, and copious errors, to learn which messages to ignore on first reading job output, as many are either irrelevant or non-productive. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Terminology
On 11/21/2011 4:32 PM, Rick Fochtman wrote: - "negation symbol", but informally called the "not sign". The only name I heard for it, that I remember, was "inverted circumflex". How about that for a meaningless mouthful? :-) There is a name for an inverted circumflex, but it's not a not sign, but rather a caron, or hacek (with one on top of the c). My grandfather had one in his name. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Simple record extraction from a sequential file
On 11/21/2011 6:13 PM, John Gilmore wrote: I am of course familiar with production-control schemes. Production must be orderly, but in my experience bureaucratic controls alone do not reduce errors: They only diffuse responsibility. Some of us are handicapped by management uneasy with things they do not understand. Rigid and rigorous procedures for adoption of production changes are the most benign form of this; I worked as a contractor at a site where we failed to convince management that a particular approach would save them time and money. A manager unable to complete a work load in a batch window has plenty of excuses the higher-ups will understand (more work to process - we need a faster machine), whereas a radical change the manager can't explain may result in unemployment at the slightest hint of a problem. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: STOW macro Location
On 11/15/2011 9:24 PM, Paul Gilmartin wrote: Resource constraint, whether development schedule or REGION to accommodate the executable code is a plausible explanation. All of the OPEN code was in a type 4 SVC, with a 1K constraint on each transient. While OPEN had a lot of overlays, it didn't exhaust all valid names, and if necessary, an extra one for the member name check could have been added. The REGION doesn't come into it. But that was then; this is the 21st Century. A reasonable compromise which allows the user to do something "this strange" would be to allow the operation if the user overrides to DSORG=PS, in either JCL or SVC 99 arguments but forbid it for DSORG=PO. (It's probably a bad idea to permit this override for PDSE.) Agreed. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: STOW macro Location
On 11/15/2011 8:41 PM, Shane wrote: Maybe users in bygone times were made of sterner stuff and prepared to take responsibility for their own actions. Not necessarily - we operated in a completely different environment. There were so few manuals that it was possible to read all of them, as well as their updates, and if you didn't understand something, it was easier to run tests until you determined what was happening. Stand-alone machine time was easier to get, and source code was available on microfiche and tape. Maybe IBM never put any thought into it at all. My guess that it was a typical IBM process - technical staff raises an issue, and a bean counter shoots it down for lack of a business case. After all, everyone backs up their files, right? Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: STOW macro Location
On 11/15/2011 7:38 PM, Bill Fairchild wrote: I think the real culprit is the lack of user-friendliness in whatever OPEN executor module is blindly following the user's request to overwrite an entire file without checking for certain file types for which overwriting the whole file might not be appropriate. This module, whichever one it is, could easily check if the user is attempting to use any access method other than BPAM to write into a PDS and has not specified a member name, and, if so, then this module should return an error condition. Perhaps IBM reasoned that if a user really, really, seriously wants to do something this strange, they should let him. IBM was in a big rush to get OS/360 out the door, and may not have considered that worth worrying about. The attitude seems endemic - just look at all the commands handled by the communications task that let the operator set and change things, with absolutely no feedback on the current status. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: STOW macro Location
On 11/15/2011 5:56 AM, Elardus Engelbrecht wrote: To Binyamin Dissen and Shmuel Metz: Ok, I must be confusing (having too much decaying braincells :D ) STOW with something else which can destroy a PDS / PDSE directory if used incorrectly. Or perhaps you were thinking of STOW ,,,I ? Re your comment on using members as sequential data sets, that's fine as far as it goes. But sometimes you need an alias, or more frequently user data for a member. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Data encrypt
On 11/15/2011 10:35 AM, Ron Thomas wrote: The customer number we are currently having the ssn as its identifier, we need to make sure this has to encrypted . Let me know what process we need to follow over here? While I'm not a lawyer, I was under the impression that using an SSN for anything other than Social Security and Internal Revenue Service was illegal. Even if your use is sanctioned, you need to consider that an SSN is not guaranteed to be unique; depending on your usage, this may become problematic (the IRS has a data file for non-unique SSNs, with additional data to disambiguate them). Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: The "IBM Displays" Memory Lane
On 11/13/2011 4:47 AM, Leonard D Woren wrote: The 2250 MCS console support was flaky; I once crashed something (38 years later I can't remember if it was just the 2250 or all of MVT) by idly clicking the light pen aimed at the fluorescent lights in the ceiling. Interestingly enough, MVT supported using the light pen to click on the MCS console for the functions of "K D,F" and "K E,D", and I have a really vague recollection that there were numbers you could click on for the equivalent of PFK-assigned commands. When we got our 360/165, my first impression was that the 3066 console looked like a stripped 2250, complete with a cursive character set, and minor flickering. I wrote code to run it with EXCP, and was impressed by being able to use a mixed Read/Write CCW chain that preserved user input while updating the screen outside the input area, and no keyboard lockup. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Data Areas?
On 11/11/2011 5:37 PM, Steve Horein wrote: Unfortunately, I'm not familiar with the term OCO. Like I mentioned, IOVT/IOCIOVTP isn't the first address I've encountered that once I got there, I didn't know exactly what I was looking at! I do think the Data Area manuals are extremely helpful by noting the size and the different information contained, but I seem to hit a dead end. When IBM first released the System 360, all software was made available in source form, in addition to the normal distributions of object or load module format. When we ordered a new release of OS/360, we also ordered the optional source material tapes, and the matching microfiche. In addition, fixes were available both on tape, and their source on microfiche updates. In the sixties, IBM was sued by Applied Data Research for distributing free software (purportedly) similar to what ADR wanted to sell (ROSCOE vs. IBM's CRBE/CRJE). The outcome was IBM's decision to charge for all software other than the base system. In the seventies, a company a friend of mine refers to as Jujitsu took the entire MVS system code, removed all copyright statements, removed all references to IBM, made some minor changes, and sold the resulting system with its own hardware. IBM's response, other than a court case, was to restrict all source code (other than HASP/JES2) from distribution, and to cease making the optional source and fiche available. They referred to this as Object Code Only (OCO). A result is a lack of needful information in manuals, as you noted. Some of us look through dumps, and trace execution flow, to figure out what is happening, but that's a gray area, as IBM's standard contracts prohibit reverse engineering. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3270 archaeology (Was: TSO SCREENSIZE)
On 11/11/2011 3:34 PM, Shmuel Metz (Seymour J.) wrote: Then you should have ordered from GTE :-( The one that didn't handle wrap-around correctly? You didn't have the STC (later STK) tape drives where only every other jumper position was used but the CE documentation didn't mention the fact? At one time we had a string of STK drives, but they gave us nothing but problems, and were replaced with Memorex hardware very quickly. I vaguely recall you grumbling about the CIG[1] block multiplexor channel as well. Only until they fixed the timing (3350 response came before channel was able to handle it). Memorex plugged their controllers for slower response, thus giving us support for 3330-1 and 3350 capacity, but without the speed improvements. I fondly recall referring to it as the PIG multiplexer Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3270 archaeology (Was: TSO SCREENSIZE)
On 11/11/2011 1:07 AM, Larry Chenevert wrote: The channel attached control units for those 3270's were notorious for generating interface control checks, which the operating systems of the era (OS/VS1, SVS, and MVS 3.8) were notorious for responding by entering disabled waits, resulting in many unscheduled outages, and this seemed to persist into the early 80's. Your experience differs from mine. We usually installed new hardware over weekends, and gave it a thorough workout before acceptance. While we had occasional channel checks, it was only during the initial testing. I have no recollection of problems (other than normal failing boards) with the controllers (we ran IBM 3272s, then 3274s, later lots of ITT and one AT&T units. Only the AT&T and one Telex gave us problems). It makes me wonder whether your problems might have been due to other controllers on the channel (I know at least one installation that hooked their 3270s on the same selector as their tape drives!). The worst incident I recall was when the C.E. was asked to plug a new 3272 as address 0C0, and he held the board upside down. We had a TP controller on 030 and had lots of interesting errors until we made him fix the switches. The other major problem was an installation where the C.E. didn't hook up the EPO cable, and after he left, the 4341 CPU wouldn't power up. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TSO SCREENSIZE
On 11/10/2011 4:15 PM, Mike Schwab wrote: And the original IBM 3270 screen size was Model 1, 12 lines by 40 characters. Model 2 (24 * 80) didn't come along until later. I seem to recall the model 2 to be available at the same time as the model 1, but that may be due to my dismissing the model 1 as useless. At the time we were running 12*80 2260s. (And while google may be my friend, in this case it turned up nothing useful) Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMFPRMxx ACTIVE/NOACTIVE parameter and SMF exit IEFACTRT
On 11/10/2011 4:14 PM, Rick Fochtman wrote: This is the behaviour I would expect. IEFACTRT is dependant on the data collected by SMF processing. No SMF processing means no data, therefore, no reason to even attempt invoking the exit. While irrelevant to the OP, IEFACTRT antedates SMF by a few years (note that SMF exits have an IEFU prefix), and I used it for accounting prior to the availability of SMF data. IBM normally tends to be pretty conservative about keeping things working, so my expectation would be for IEFACTRT to be invoked even without SMF active. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OT measures was Re: Out damn'd GMT ...
On 11/8/2011 8:29 AM, J R wrote: ... Two by four construction lumber is still the same dimensions (more like 1.6in by 3.2in). And in the UK, they still call it four-by-two (otherwise Cockney rhyming slang wouldn't make sense) and it is a lot closer to its nominal dimensions. If I had to guess, it's because the UK is a lot more humid and the lumber wouldn't shrink as much? Makes me wonder whether dimensional lumber in Seattle is bigger than in Texas. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OT measures was Re: Out damn'd GMT ...
On 11/4/2011 11:31 AM, Clark Morris wrote: Canada may be officially metric but I am looking at an advertisement for meat at $4.99 a pound at my local grocery here in Nova Scotia, Canada. Canada is all screwed up We bought jewelry, chocolates, and a book at a Halifax mall, and each receipt had a different date format. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: STP and Time Change
On 10/31/2011 8:17 AM, Tom Marchant wrote: If the application uses local time and will have problems during the second hour between 1:00 and 2:00, you will have to shut the application down for an hour. Unless the time requests are used for interval calculations, it should be possible to install a hook into the time processing, similar to what was popular prior to the Y2K debacle, to return a fake time (at 1 a.m. daylight time the intercept would return 1 a.m., at 1:10 say 1:05, and at 2 a.m. normal time it would be synchronized again). If the application is mission critical, that might be preferable to a one hour shut down. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DSCB DSECTs?
On 10/28/2011 3:09 PM, Kirk Wolf wrote:
Here's some pseudo-code for how I think it is calculated:
used_tracks = DS1LSTAR.TT (the first two bytes of the TTR)
if (DS1STRP) {
used_tracks = (DS1TRBAL<< 16) + used_tracks; // two new high-order
bytes
} else if (DS1LARGE) {
used_tracks = (DS1TTTHI<< 16) + used_tracks; // one new high-order byte
}
This seems odd to me - am I understanding this correctly?
Can't comment on the rest, but for classical data sets, the use
is either zero, when TT and R are zero (as for a PDS/E, HFS,
etc.), or TT+1 (e.g., an empty PDS with 1 directory block would
have TTR=01, and TT alone gives you an incorrect 0 when you
need 1.
Gerhard Postpischil
Bradford, VT
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems calling IDCAMS:
On 10/28/2011 3:39 PM, Joe Aulph wrote: The code is not-reentrant, I've done no GETMAIN's, has anyone ever ran into this sort of thing? Any help would be appreciated. Your second sample doesn't show you loading R1 after the LOAD. If that's not it, then the most likely cause, in my experience, is that your program is doing something nasty, perhaps (re)using the SYSIN/SYSPRINT data sets, or overwriting storage, or shifting to an inappropriate addressing mode. In the case that your DD names are also used by the program, you could change ARGLIST to include substitute DD names for input and output DDs, to see if that changes anything. As I mentioned yesterday, in assembler it is possible to call IDCAMS with a parameter list that enables an input and output exit, so you do not need to allocate unneeded SYSIN/SYSPRINT data sets. While it takes a little effort to set up the first time, it's nice to have in the long run. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Lines per page - IDCAMS output
On 10/27/2011 6:36 PM, Dale Miller wrote: Frank Bonaduce wrote: "Another possibility ... is ... IGGCSI00. If you are versed in Assembler ...". I need to point out that Assembler is not necessary. REXX will do just fine. The only thing that counts is getting things to work, so if you use REXX rather than assembler that's fine. However, IDCAMS may be invoked from assembler using the SYSIN/SYSPRINT exits, making the process more efficient. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Our community strengths
On 10/27/2011 7:08 PM, Dale Miller wrote: machine. I only stopped using Warp when it became impossible to get a new printer with Warp support, and my old EPSON laser EPL6600 finally died after quite a few years of unblemished service. I built my own machine in 1984; the only change was to replace the 64K motherboard with a 256K one a few years later. Has been running Warp without a hitch, while several Windoze machines have come and gone. My current printer is a Kyocera 1600; it and supplies are available on eBay. There are other printers out there that do not require Windows or Mac drivers. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CRLF in unix, translated :-)
On 10/26/2011 11:44 AM, Tony's Comcast account wrote: I looked them them up but due to my limited gray matter I no longer know the capital of Bulgaria or who composed La Traviata. Really hard to believe But get a piece of paper and write down Sofia, and Joe Green for future reference. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Lines per page - IDCAMS output
On 10/26/2011 3:51 PM, Binyamin Dissen wrote: When you suggest RTFM, make sure that there is something in the FM. Otherwise, what is the point of a useless suggestion? There are way too many new users addicted to the internet, who are used to asking a question and getting an answer, without having to think or do any work. The point is that, in the long run, it creates good habits. If the OP states that he looked at manual xyz, page nn, and didn't understand it or it doesn't seem to work, then the answer will be a lot more useful, and the number of posts both ways will decline. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: BLDL error Cause
On 10/24/2011 8:19 AM, Tom Marchant wrote: Did I miss the announcement that block sizes greater than 32K are supported? What release was that? It depends on your definition of "supported" - I had a job that used BSAM to manipulate blocks larger than 32K (disk and tape). If you have an even number of buffers, it's quite easy to overlay the relevant BSAM control blocks and CCWs with larger sizes. QSAM might be a bit harder. These days it's easier to use EXCP, since much of the detailed error handling can be avoided. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS Control block question
On 10/19/2011 6:38 PM, Roberts, John J wrote: I just ran a test using my z/OS 1.11 system and it worked. And a stopped clock is correct twice a day. If I had a dollar for every problem in your little code segment, I could buy something nice at Starbucks. 1. There is no check to handle a deleted entry. 2. The code should save the caller's AMODE (e.g., BSM 14,0 / STM 14,12,12(13) at start; BSM 0,14 at end) and switch to AMODE 31, as pointed out by Shmuel. Having AMODE and RMODE statements in your assembly indicates a preference, but is not enforced at execution time. 3. The code is inefficient. There are unused registers, but it accesses TIOELNGH twice. It would be simpler to do an ICM at the top of the loop, branch out of the loop on zero, and at the end of the loop, just add that register to 14. 4. Your RX instructions use index registers rather than base registers [e.g., L 2,0(1) instead of L 2,0(,1)]. That may cause problems when called by a program that uses access registers. And if you don't need to update the access register, the code is easier to maintain if that's shown explicitly [LA 15,54(15,0)] 5. And as I mentioned originally, you must either treat the JFCB address as an SVA (preferred), or test whether it's an address. While SVAs are odd, IBM has made no commitment to that effect, so using SWAREQ is the preferred approach. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS Control block question
On 10/19/2011 5:29 PM, Roberts, John J wrote: My little subprog: SR1,1 ICM 1,B'0111',TIOEJFCB LOCATE JFCB MVC 10(44,15),16(1) This always works only in older systems. For current ones, the TIOEJFCB field is a double index into SQA, and you need to use SWAREQ (unauthorized for retrieval) to get the virtual JFCB address. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Rename of DDname ?
On 10/7/2011 9:45 AM, Thomas Berg wrote: An example of usage is when You have an allocation for application 1 with DDname 'ABC' for dataset AAA.BBB and want to keep that and then want to run application 2 which requires the same DDname (for dataset CCC.DDD). This is just *one* example. Is it a matter of "editing" the TIOT, or ? This is feasible only when the called programs support changing the name (e.g., many IBM utilities offer an optional DDNAME list on invocation). Changing the TIOT (alone) wouldn't help, as there are other control blocks with the name. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Object modules
On 9/13/2011 12:26 PM, Tony Harminc wrote: I wouldn't say that. I'm not aware of a case where a delinker will silently produce an object deck that doesn't match the load module. Back in the sixties I ran into a problem with a module that had several CSECTs from a single assembly. DELINK0 appeared to work correctly, but the linker forced one of the names to a double-word boundary which it hadn't been before. I no longer recall the details, and haven't seen the problem since, and I long ago lost the output. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: A Set and B set of z/OS system
On 9/8/2011 8:30 AM, Mike Schwab wrote: On assembler programs, when a statement is continued onto another card, columns 1-15 must be blank and your text begins in column 16. Please suggest. You misread his message. He wasn't asking for the answer, but a suggestion of how to find it Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS Systems Programmer Jobs in Dubuque Iowa
On 9/8/2011 12:21 PM, Paul Peplinski wrote: That is all true and good for situations you mention. The problem with that is when nearby companies do "market analysis" of wages it gets to be an infection that spreads quickly. If someone is willing to disregard personal ethics, it would be interesting to provide work of a quality commensurate with the salary. I once was hired as a consultant at an IVP, with a twenty year old product that suddenly had become unstable. It turns out they hired (in succession) two programmers with no apparent assembler or hardware experience; I found over a dozen MVC and CLC instructions where one of the operands was a character self-defining term (e.g., MVC FLAG,C'X'). And those were only the obvious errors. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: A Set and B set of z/OS system
On 9/8/2011 1:01 AM, saurabh khandelwal wrote: 53 LOOP UCBSCAN ADDRESS,WORKAREA=WA,UCBPTR=UCBADD,NOPIN,DEVCLASS=DASD,X DYNAMIC=YES,RANGE=ALL,LOC=ANY ** ASMA144E Begin-to-continue columns not blank - DYNAMIC=YES,RANGE=ALL,LOC=ANY Please suggest. The message is self-explanatory. If not, read the assembler manuals. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF timestamps
On 9/6/2011 11:04 AM, Richard L Peurifoy wrote: Perhaps we need a requirement for an option to use GMT in the SMF header, or maybe to just use TOD timestamps. It would be nice to have the GMT offset in the records too, but this would require changes in the record structure which will be harder to do. The easiest would be to keep existing formats, but add a new SMF record type that would record clock information whenever that is changed (including the daylight savings transition), and provide the IPL settings. While it would be lovely to have only TOD timestamps, there is no business case for a complete SMF rewrite. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Book: What On Earth is a Mainframe?
On 8/26/2011 5:43 PM, Phil Smith III wrote: Ok, but it's not "MVS" any more. Do you drive a Model T? Is your desktop a 486? Do you run Windows 95? In 1984 I built a PC from parts - Intel 386 on an AT format motherboard, with one 5" and one 3.5" floppy. It's not connected to the internet, has never been hacked, and stays up during power outages even when my Wintels quit. I use it for finances and personal data base work, running OS/2 in the primary partition and Windows 95 in the secondary (mostly games there). It's rock solid, doesn't get blue screens of death, and is a better designed system than the alternatives. In this same time I've gone through several PCs and versions of DOS and Windows, at much greater expense. If the model T had four wheel drive, it might be preferable to my current car in winter and mud season Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYNCH[X] vs LINK[X]
On 8/23/2011 3:10 PM, Micheal Butz wrote: On Aug 23, 2011, at 2:47 PM, Gerhard Postpischil wrote: On 8/23/2011 1:05 PM, Micheal Butz wrote: If I have a peice of code that was MVCL somewere it can'nt be the object of synch/synch OK, I'll bite - why not? > In a earlier post John Gilmore wrote as long as the copy is > refershable reusable the Info is kept in the CDE Apples and bananas. SYNCH has nothing to do with CDEs, as already mentioned. The only possible hitch with moving code is that the code either must be self-relocating, or not contain affected address constants at all. Neither consideration precludes the use of SYNCH. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYNCH[X] vs LINK[X]
On 8/23/2011 1:05 PM, Micheal Butz wrote: If I have a peice of code that was MVCL somewere it can'nt be the object of synch/synch OK, I'll bite - why not? Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Security is fun in the PC world....
On 8/20/2011 12:27 PM, Elardus Engelbrecht wrote: I agree, zMan (and many others) is still anonymous despite being asked, in IBM-MAIN many moons ago, for his/her/it identity despite his famous signature line. This looks like a good opportunity to nitpick. I consider a contribution to be anonymous only if you can't identify the sender, in the sense of disambiguating two messages both sent anonymously. In our case you always know whom the message is from, just not the identity of the sender, so I'd call him incognito instead Perhaps zMan may give himself lots of trouble by giving out his name. Let us hope he can do that in the future by retirement... (and share some zMachine warstories too... :-D ) Some installations are supersensitive, and may try to control their employees even when off site, though in this day and age this is getting to be more and more futile. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Security is fun in the PC world....
On 8/20/2011 9:37 AM, zMan wrote: In case it's escaped you: http://www.lmgtfy.com/?q=%22kevin+mitnick%22 1.3M hits. Heavily covered by popular and trade press. Hardly obscure. While I don't know about the others, MCI in the late seventies was definitely running IBM systems (MVT up to 1978, pre-RACF; I don't know what they ran once they got their own computer center in DC). Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: iasxwr00
On 8/19/2011 5:43 PM, Ed Gould wrote: As far as I know the program (even if run) would not produce any output no Input. There is a block letter subroutine that is probably useful (Can't remember the name for the life of me) that I used eons ago for a calendar) it was easy to use but how often do you need to create block letters? I suspect you're thinking of IEFSD095, which in its original form lacked national characters, and so was useless for printing job separators. IIRC, there is an improved version on the cbt (by either Bill Godfrey or Jim Marshall?). I did my own version with all PN train characters, an 8*8 matrix, italics, and a few other enhancements in the seventies. On top of that it appeared to have been written by a 7094 programmer, using full-word instructions for character manipulation; definitely not one of IBM's finer efforts. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SV: PDS(E) "invalid" membernames give suprising behaviour in ISPF Data Set List Utility (BROWSE)
On 8/19/2011 5:13 AM, Thomas Berg wrote: 4. You can update JFCBELNM with member name consisting of characters that are not limited to those which can be specified in JCL. The member name cannot consist of bytes that all are X'FF'. 5. Process the member with an OPEN TYPE=J macro, a series of PUT or WRITE macros, and the CLOSE macro. The system issues a STOW macro when the data set is closed. Note: If the member name specified in JFCBELNM begins with '+' (X'4E'), '-' (X'60'), or X'Fx', the system does not issue the STOW macro. CLOSE will interpret '+' (X'4E'), '-' (X'60'), or X'Fx' in JFCBELNM as an indication that the data set is a generation data set (GDS) of a generation data group (GDG). That sounds like a reportable error. JFCBELNM is not supposed to be relevant unless JFCBIND1 has either the JFCPDS (member name) or JFCGDG (generation number) set on. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Last card reader?
On 8/18/2011 5:30 PM, Rick Fochtman wrote: because he was just too afraid to be confident of his work. I couldn't be troubled to double-check his work and still get my work done. Where do you draw the lines? I've worked at places that separated test and production environments, and to even have your work considered for production testing it had to be checked by another. It's generally cheaper to pay for extra employees than to fix costly problems, or worse, put trojan horses into your system. And I've had a few doozies - one program should have had an LA instruction that got keypunched as an LH; the error was discovered fourteen years later when IBM changed a control block around so the referenced field wound up on an odd boundary. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ABEND - 637-04
On 8/18/2011 1:16 PM, john gilmore wrote: Seymour's comment about 32K BLKSIZE= values for "load libraries" needs qualification. It is on the mark for traditional PDSs containing load modules. It is off the mark by a factor of 8 for PDSEs containing program objects. They have an imposed block size of 4K, which should not be/need not be mentioned. The thread started with a discussion of efficient use of DASD. A 32K text record in a PDS takes up less disk space, allowing for block overhead, than 8 4K blocks in a PDSE. The physical block size in a PDSE does not enforce a restriction on a data set block size. If you are asserting that the Binder reverts to a logical 4K size, then the PDSE would at best match, or come out slightly worse than a PDS with a 4K block size, due to design. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: UNIX (USS)
On 8/18/2011 3:43 AM, Paul Gilmartin wrote: Yes. If it were a PARMLIB option rather than an exit facility, I might not consider it a hack. If it were the default, I wouldn't consider it a hack. But is this for a different LPARs, or for a single LPAR? The pre-logon exit has an option bit to suppress the enqueue on SYSIKJUA. Doing so enables multiple logons on the same system. What happens is up to the exit code - it may issue a shared ENQ, escalate the scope to SYSTEMS, or whatever the installation can dream up. Since the advent of ISPF, I wouldn't recommend running multiple instances in different sessions, but an installation might even be able to work around that. Offering it as a PARMLIB option would not be advisable, as it would lead to wholesale destruction of data sets by unwary users who accidentally or otherwise do multiple logons. My exit presented prompts (line mode terminal) or a formatted screen for logon (didn't use USS), and displayed options that were verified against the user's privileges (our security was based on account numbers), so it was fairly easy to restrict goodies to trained users. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: UNIX (USS)
On 8/17/2011 8:50 PM, Paul Gilmartin wrote: Get a workstation. Run as many tn3270 sessions as your heart desires. Then complain that TSO won't allow you to run multiple sessions. (I know; there are hacks that fix that. Sort of. It just isn't standard.) Does this mean your definition of "hack" to be the use of an IBM provided option in a supported (pre-logon) exit? Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Last card reader?
On 8/17/2011 4:36 PM, Robert Heffner wrote: I was going to add that there is a small company in Texas that not only still uses cards, but uses a 402 to process them. Talk about one for Ripley's. My all-time favorite is a small establishment on Times Square in New York City. A customer would provide details, the attendant would punch stuff into a card, shuffle it into a deck of a couple of hundred other cards, and run them through a card sorter. After a few times, exactly one card fell into the "lucky" slot, containing the customer's fortune. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: file allocation dcb order
On 8/11/2011 5:04 PM, Rick Fochtman wrote: I respectfully submit that the use of SVC 32 is archaic and cumbersome and should be discouraged in favor of DYNALLOC (SVC 99) whenever possible. I have a 33.3 RPM turntable, cassette tape recorder, VHS recorder, and I have been known to use a manual screwdriver. I even look at maps when I need to drive somewhere. When something works, age should be a secondary consideration to capability. SVC 32 allows some things to be done that are difficult or messy with SVC 99. If you railed against DAIR I might have a little more understanding. How many of our list participants are sufficiently skillful to construct a partial DSCB correctly? Most of the dinosaurs, who had to run OS/360 despite IBM's help. Completing a DSCB is no more difficult than setting up a JFCB. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CAMLST LOCATE and SCRATCH
On 8/10/2011 7:50 PM, Scott Ford wrote: I need a little help, maybe a lot of help. I wrote an Assembler routine that is able to locate a dataset non-racf, non-sms and the routine finds it fine , no problem. When I go to CAMLST SCRATCH it i have a S0C1 it looks like in dfp...So here is my of my source showing LOCATE and Scratch. The input dsname in coming in off SYSIN... You should not be getting an 0C1, but rather an error message. 1) You may use the same physical CL44 field for all requests, using the same name in the CAMLSTs. 2) SMS data sets are funny; you may only think you have a non-SMS data set? You need to look up the messages and the error codes. I prefer to use a DELETE (non-VSAM) statement with IDCAMS. You may LINK or ATTACH to IDCAMS passing it a SYSIN/SYSPRINT exit list; in the SYSIN exit you return the DELETE statement(s), then end of input. In the SYSPRINT exit, you choose whether to print or ignore the text given to you. It's a little more overhead, but well worthwhile. The information about the exits is in a figure, not the text, so some types of reader don't show it at all. If you want sample code, let me know. Also if the LOCATE returns a MIGRAT as the volume serial, you can use an HDELETE statement to get rid of the data set without a recall. 3) SCRATCH may need an OVRD parameter. 4) The 0C1 at location 52 means that you tried to do an I/O (GET, PUT, etc.) to a closed DCB. Your fragment doesn't show a DCB for SYSPRINT, nor the OPEN and CLOSE statement; and if you have those, you could be missing the DD card. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: batch job as non-swappable
On 8/10/2011 1:50 PM, Tim Brown wrote: What is required to make a particular batch job run as non-swappable It has to run authorized, and issue a SYSEVENT, either TRANSWAP or DONTSWAP. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Enforcing job name conventions - which exit?
On 8/9/2011 11:27 AM, Williamson, James R wrote: IKJEFF10 Customizing how users submit jobs and process the output As the OP pointed out, the request was for a general solution, not just from a TSO SUBMIT. And you might be astonished at how many installations write elaborate code for this exit, but do absolutely nothing to a job submitted (TSO or otherwise) via DD SYSOUT=(x,INTRDR). Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SETLOCK in IEFU85
On 8/9/2011 11:54 AM, Donald Likens wrote: seemed to work. PS. I anchor the buffer in a module dynamically loaded into LPA. When I designed this I wasn't even sure I could do a getmain in IEFU85 since it could not issue SVCs (I have since learned obtain storage does a PC). It is expected that modules loaded into LPA be reentrant (or rather, refreshable). You could use that method only if you also pagefix the page containing your pointer (and if you do your initialization with a job, the fix needs to survive job termination). As an alternative, you could specify the module to go to FLPA via a PARMLIB entry. I'd look for a more mundane solution. If you don't like name/token services, another alternative is to use a subsystem entry; that can also be created dynamically, and has fairly low access overhead. Probably the most efficient way of anchoring things is to use the CVTUSER slot (pointing to a table, for expansion), but that makes your code installation dependent, as everyone else finds this tempting also. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Opcode X'A0' (was:Suffix of 64 bit instructions)
On 8/8/2011 11:05 PM, John Baker wrote: The X'A0' opcode provided various VS APL Assist functions. I don't believe that IBM ever documented it in any publication distributed to customers. In the sixties I wrote a little program to run through all possible opcodes, which turned up some undocumented ones (returning an 0Cx other than 0C1, or executing); of course that didn't tell me what they were. Also IBM CEs had a rack of machine service manuals and logic charts; these were readily accessible, and sometimes quite revealing. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Suffix of 64 bit instructions
On 8/7/2011 8:48 PM, Robert A. Rosenberg wrote: Thanks to the Wikipedia S/360 article I was able to download a copy of the S/360 PoPs manual can confirm my impression that ALL the S/360 opcodes were one byte long (and that B2 opcodes were not part of the architecture). In Fact - No opcode from A0-D0 was valid. If you are confining yourself to normally used instructions, then you are correct. Depending on your interpretation, the opcode for Diagnose was three or four bytes, and just about every 360 model used different values. On the 360/40 I used one to read the panel switches, and another that causes all tape drives to rewind, unload, and power off. Similar ones I tried on the 360/50 gave me a machine check unless I/O was quiesced beforehand. And I seem to recall that A0 was the opcode for loading emulator instructions on the 360/165. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Source code to Milten, Orvyl, & Wylbur is here.
On 8/4/2011 2:37 PM, McKown, John wrote: I vaguely remember using these in college on MVT. The actual HLASM source is available. It's liberally licensed in a MPL type license. Now, this is not likely of much use to us here. But if you're running MVS 3.8j or MVT on Hercules/390, this might be of some interest. http://www.stanford.edu/dept/its/support/wylorv/ This has been available for a number of years, but it's of limited utility. Some person moved mainframe data to a PC environment without consideration of the character set, resulting in loss of some special characters in the code, module names, and directories. No effort was made to keep it in a mode easily retrievable for mainframe use (I wrote a little REXX utility to combine files in one directory into IEBUPDTE format, but couldn't fix the special character problem). The code is incomplete (some missing source has assembly listings). It's further not really useful on MVS 3.8 because it requires HLASM features (e.g., it uses dynamically generated global variable names, and the D' attribute). I tried the Dignus assembler, but had problems with it. Installation specific code for logon and accounting should be replaceable, but is fairly embedded. And finally, the code for asynchronous terminal support isn't included, as they moved that functionality into a custom front-end. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: S/A Dump issue
On 8/3/2011 5:25 PM, John Norgauer wrote: IEAIPL0010/31/06 HBB7740. Strange stuff going on here with my S/A dump writing. Just a shot in the dark, but similar to the IPL text, is it possible that the S/A dump module has a dependency on the version of the system you're running? The Halloween 2006 date seems pretty old. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: "programmable SYSOUT"
On 8/3/2011 1:25 PM, Scott Ford wrote: Yep, Shmuel we have a couple customers asking for a 'generic' wilbur or roscoe type interface. It amazes me that people are still using Wilbur or Roscoe.. Why should it? For some users, and some applications, using a "dumb" terminal, with user configurable tabs, provides the fastest means of data entry. And with a properly modified Wylbur, you can get full-screen support on an asynchronous CRT, and have full-screen editing, too. While I've installed and maintained ROSCOE, I've never used it, so can't comment. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CORRUPT PDS - I/O ERROR
On 8/3/2011 8:38 AM, CM Poncelet wrote: Well yes, they have to be loaded into VS to be processed. In the case of block read/writes they precede the data records in the buffer. But whatever was being discussed at the time I wrote that had to do with record read/writes, in which case the BDW and RDW would not be accessible from the buffer: so perhaps I should have said 'not accessible' instead of 'not loaded'. And you keep digging a bigger hole. While I have written production programs in many languages, most of my career was spent on assembler, on multiple platforms. If you had bothered to look at BSAM and QSAM, you would not be making these absurd statements. While QSAM has a DATA mode, normal use of variable format always includes the RDWs. In the original context, other than references to IEBGENER, there was no mention of the program's language, so you're on shaky ground; and IEBGENER definitely uses QSAM, or BSAM, as appropriate, with full access to the control data. If I dealt only with MVS, I would have the time to refresh my memory: but I don't; I work with subsystems. By CCW EXCPs I am simply emphasising the fact that the channel programs (CPs) are issuing CCWs (which have direct access to DASD devices). And more of the same. EXCP is a specific reference to an MVS service, and the macro used to invoke it. EXCP uses CCWs, CCWs don't use EXCP. And channel program do not issue CCWs, they are CCWs. True. I translate my thoughts into words and for this I use whatever suitable word - not necessarily the most appropriate one - first comes to mind. This group is about sharing information about mainframes, and providing help to people who are stuck. That entails effective communication, which is not achieved by using well-understood concepts in inappropriate ways, or creating your own arbitrary definitions for common words. I get the impression that you misunderstood something in the original thread, made an inappropriate post, something all of us have had happen at some stage of our careers, and rather than own up to the misapprehension, you are trying to argue your way out of it. That not only wastes everyone's time, but has already made you appear incredibly foolish. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CORRUPT PDS - I/O ERROR
On 8/2/2011 3:11 PM, CM Poncelet wrote: this. But in any case the BDW and RDW would not be loaded into the buffer. The BDW and RDW are always included in the buffer. They may not be seen at the application level (e.g., on a ForTran read or write, or in CoBOL). I have no time for that. If something is true it can remember itself; if it is false it is not worth remembering. Hence I remember what I am dealing with and forget it afterwards. Do you expect me to *remember* system control blocks? But as is obvious from this thread, you are making assertions based on (mis)information where you should have refreshed your memory. I still don't know what you meant by "CCW EXCPs", for example. 'DCB' is shorter than the 'RECFM=,LRECL=,BLKSIZE=' I am actually referring to when I say 'DCB'; so I say 'DCB' for short. 'Data format' is also shorter than those, and a lot less ambiguous. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CORRUPT PDS - I/O ERROR
On 8/1/2011 9:53 PM, CM Poncelet wrote: Quite possibly; but it's a contrived case where the 2nd LRECL is a fixed length multiple of the first (so there is one BDW and one RDW, and the records follow each other consecutively in the buffer). His example used RECFM=FB, so there are no BDWs and no RDWs (if there were, then the first four bytes of the second record would be the RDW, not data). to avoid I/O errors. Hence, the assertion that DCB attribute override priority is 'program -> JCL -> DASD' is true if the DCB is opened for output; but it is false (or at least 'it does not work', for the benefit of those who can stomach only a politically correct version of the truth) if it is opened for input, because it then hits I/O errors. DCB is short for Data Control Block. These exist only in memory, and are specific to the zOS operating systems (and earlier MVS and OS/360). I can read DASD written on MVS on VSE, and vice versa. VSE has no DCBs, but it manages to read data anyway. On DASD, each block of data is preceded by a count field containing a logical (alternate track) or physical address (CCHHR), a key length, and a data length. There is no RECFM, no LRECL, and the physical block may have a length other than that specified by BLKSIZE. Regardless of how often you repeat yourself, there is no DCB on DASD. Furthermore, your discussion of I/O seems to indicate that either you do not understand English, or that you are unaware of the differences between BSAM and QSAM. I would suggest that you read up on system control blocks, notable the IOB and ICB, look at some in a dump, and get a better understanding of how I/O functions. Requisite manuals are available online. While "Using Data Sets" is a bit daunting, it contains most of the information. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CORRUPT PDS - I/O ERROR
On 8/1/2011 9:18 PM, CM Poncelet wrote: If the DCB had 'FB,80' and the actual data had 'FB,90' - then I would expect the first 80 bytes to be read in, then the next 81st to 160th bytes etc. until all the data had been read in using 'FB,80' (and with the last record in a block being appended with X'00's, if necessary, to complete the 80 bytes). Your expectation runs afoul of reality. If the block is not a multiple of 80 (as well as 90), then the I/O fails (incorrect length), and your program would get a system 001 abend. Your scenario can be produced using EXCP (or EXCPVR or STARTIO) or BSAM, provided the CCWs had the SLI bit on, and you had code to zero the buffer prior to the read, and your deblock code went past the block end. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
On 8/1/2011 10:27 AM, Ward, Mike S wrote: Gerhard, I'm sorry for laughing at your post, but it struck me as funny. Did you really mean to say masticate? Yes, that's how I remembered it. Unfortunately others don't. See http://en.wikipedia.org/wiki/Claude_Pepper Part of American political lore is the Smathers "redneck speech," which Smathers reportedly delivered to a poorly educated audience. The "speech" was never given; it was a hoax dreamed up by one reporter. Smathers did not say, as was reported in Time Magazine during the campaign: Are you aware that Claude Pepper is known all over Washington as a shameless extrovert? Not only that, but this man is reliably reported to practice nepotism with his sister-in-law, he has a brother who is a known homo sapiens,[7] and he has a sister who was once a thespian in wicked New York. Worst of all, it is an established fact that Mr. Pepper, before his marriage, habitually practiced celibacy.[8] The Smathers campaign denied his having made the speech, as did the reporters who covered his campaign, but the hoax followed Smathers to his death.[9] Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CORRUPT PDS - I/O ERROR
On 7/31/2011 12:35 PM, CM Poncelet wrote: The program's DCB attributes take priority over (i.e. 'override') the DCB attributes on DASD for OUTPUT, and the DCB attributes on DASD take priority over (i.e. 'override') the program's DCB for INPUT. If a program 'disagrees' with that and tries to override the DCB attributes on DASD anyway, with its own DCB attributes and for an INPUT, it crashes with an I/O error. Crashing with an I/O error indicates that the program's DCB was unable - not able - to override the DCB attributes on DASD. What we have here is a failure to communicate. Your statement above makes it evident that you are using "DCB attributes on DASD" as applying to the format of the data, whereas the other participants in this merry-go-round are referring to the DCB parameters in the format 1 DSCB (DS1RECFM, DS1LRECL, DS1BLKL). Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: running Assembler I/O macro code as AMODE 31, RMODE ANY
On 7/31/2011 9:37 AM, Shmuel Metz (Seymour J.) wrote: My opponent has publicly matriculated and his father was a thespian. Not the way I heard it: he was seen to masticate in public, and his sister was a thespian. There was also a third one I can't recall. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: disclosing "business" information on the internet
On 7/28/2011 2:20 PM, Frank Swarbrick wrote: Our information security officer sent the following to my manager: "The content Frank is positing does not appear to be specific to our environment. However, I am concern by the fact he posts his position, where he works, and phone number. This creates some social engineering risk, as well as discloses information about the operating systems we use. Who can I talk with to ask Frank to remove information related to where he works on this conversation thread and future ones?" Are these concerns justified or just paranoia? Just make them aware that list traffic is archived and echoed all over the place. If the security officer can't live with the state of affairs, just inform him/her that to mitigate things, the company needs to change its name, street address, all ip addresses, phone numbers, employee names and titles, and then restrict the new information from the web. As is, the horse is out of the barn..... Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: dynamic STEPLIB
On 7/22/2011 3:06 PM, Jim Mulder wrote: The only supported mechanism in MVS for adding to the module library search order within as address space is an ATTACH with a TASKLIB. This is the only supported way to set TCBJLB. As I'm sure you're aware, many users have requirements that are not satisfied by "supported" methods. I've been at this since the 709, and have had no problem finding things that could be improved. For some users it's a simple trade-off between increased productivity at the expense of some testing after system changes. Many features of zOS exist as a result of user requests, SHARE resolutions, and similar sources. Any program which modifies TCBJLB in an existing TCB is wrong to do so. I would recommend against having any such program installed on your system. The STEPLIB program has existed for decades without problems. While I can only speak for the version I'm using, it's reliable. In a sandbox environment it saves significant time for program development and testing, to the point where even an occasional system crash (not yet observed) would be an acceptable trade-off. Additionally, mine has an APF option, allowing the DEB to be flagged authorized, which saves yet more time developing system utilities. While there was an integrity exposure when it was first written, with modern security it's safe enough to put on a production system, not that I'd recommend that. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Check out June 2011 | TOP500 Supercomputing Sites
On 7/20/2011 10:17 AM, Bill Fairchild wrote: I checked it out. Japan is way out in front of the rest of the pack with an 8.0 petaflop system. The only way the USA is tops is in the total number of different systems, which is 5. This is an interesting journalistic device. If you look hard enough, you can always find some way to categorize your own contestant(s) as the winner(s). That reminds me of probably the most blatant example. Back in the seventies, the USSR and the US held a track meet, and Pravda reported that the USSR took second place, and USA was next to last! Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Re-entrant module stores into itself with no 0C4
On 7/20/2011 9:34 AM, Tom Marchant wrote: On Tue, 19 Jul 2011 21:50:21 -0400, Tony Harminc wrote: Well... I don't know, but I speculate that the failure to load most REFR modules into store-protected storage in the early days was an attempt to avoid providing an easy to use mechanism for unauthorized programs to put arbitrary data into protected storage. I don't see why that would have been a problem. Perhaps you could enlighten us as to the why that would be necessary. Remember that system integrity issues were not as well understood as they are today. I doubt that integrity was an issue, as the design of the paging system could have provided a subpool for protected pages in the user space. If a module needed to be in shared storage, the installation could put it there, thus avoiding IBM involvement. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Re-entrant module stores into itself with no 0C4
On 7/19/2011 10:18 PM, Schumacher, Otto wrote: REENTRANT Program: Re-entrancy is a useful, memory-saving technique for multiprogrammed timesharing systems. A Reentrant Procedure is one in which multiple users can share a single copy of a program during the same period. Reentrancy has 2 key aspects: * The program code cannot modify itself. * The local data for each user process must be stored separately. Thus, the permanent part is the code, and the temporary part is the pointer back to the calling program and local variables used by that program. I hate to quibble, but it's not true that the program code "cannot" modify itself. As you noted, local data are stored separately, and could, for instance, contain an ENQ parameter list. The module could do an exclusive ENQ, change itself, do something else, change back, and release the ENQ, and still satisfy all conditions of re-entrancy. REFR The module is refreshable. It can be replaced by a new copy during execution without changing the sequence or results of processing. A refreshable module cannot be modified during execution. A module can only be refreshable if all the control sections within it are refreshable. The refreshable attribute is negated if any input modules are not refreshable. Refreshable modules are also reenterable and serially reusable. A module may be refreshable, but need not be re-entrant. This has been discussed before. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Making Z/OS easier - Effectively replacing JCL with Unix like commands
On 7/18/2011 9:22 AM, Charles Mills wrote: The Mainframe version written in Assembler. The PC version is written in C. Somewhat OT but why? Why not C on the mainframe? Why two code bases, one fairly easy to debug and one relatively hard to debug? Perhaps there are historical reasons - one version existed long before Clement decided to add PC support, and the C route looked easier than converting mainframe assembler to PC? I am thrilled with writing software for the mainframe in C (C++ actually) after years of laboring in assembler. Good for you, but some of us have built extensive macro and subroutine libraries to use with assembler, and find it as fast and easy to use those than to live with (the confining limitations of) higher level languages. De gustibus. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL Question
On 7/13/2011 6:52 AM, R.S. wrote: No, in general it is matter of definition. My English is poor, but let me present another example, as off topic as dog's one: A car. In my country, Combi (Wagon) car is named in folders as 5-doors car. Hatchback is also 5-doors or 3-doors. Does anyone use the tailgate as a doors? Since we're already off-topic - yes. Some years ago the locks on my station wagon froze (we have fairly cold winters), and I had to get into the car through the back. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
