Re: More calumny: Secret Service Uses 1980s Mainframe
Slightly OT, but I was in Rome a few weekends ago (to watch England vs Italy Rugby match) and we tried to get train tickets from the airport to the City ... The automatic machine we were using froze and then gave us the Blue Screen of Death It then rebooted itself and up came OS2 Warp V3 ( ... I think it was V3 ... ( a few sherberts had been consumed on the plane !! .. :-) ) ... Brian Westerman brian_wester...@syzygyinc.com Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 02/03/2010 08:57 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu To IBM-MAIN@bama.ua.edu cc Subject Re: More calumny: Secret Service Uses 1980s Mainframe ... I think you would be surprised how many sites are still running old hardware and software. Brian -- 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 This e-mail message, including any attachments transmitted with it, is CONFIDENTIAL and may contain legally privileged information. This message is intended solely for the use of the individual or entity to whom it is addressed. If you have received this message in error, please notify us immediately and delete it from your system. Please visit our website to read the full disclaimer: http://www.euroclear.com/site/public/disclaimer
Re: More calumny: Secret Service Uses 1980s Mainframe
Peter Nuttall pisze: Slightly OT, but I was in Rome a few weekends ago (to watch England vs Italy Rugby match) and we tried to get train tickets from the airport to the City ... The automatic machine we were using froze and then gave us the Blue Screen of Death It then rebooted itself and up came OS2 Warp V3 ( ... I think it was V3 ... ( a few sherberts had been consumed on the plane !! .. :-) ) ... I see nothing wrong in that. The device you described was probably produced many moons ago. It's not new, but it's still working. No need to replace the device, no need to upgrade it. Last but not least: the license for OS/2 is OTC type - already paid, no monthly bills. I guess that new devices do not run OS/2 any longer. BTW: Sometimes the obsolete version of software or age of hardware is not an issue, but the system can be still ridiculous. Example: z9BC running 30+ years old application under z/OS. Funny? Not yet. However the application is really simple and has no strong requirements for RAS. Other companies using the same application moved to single PC (yes!) or small LAN painlessly. Many years ago. What is ridiculous? To pay for the mainframe and z/OS while regular PC would be sufficient. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: More calumny: Secret Service Uses 1980s Mainframe
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Nuttall Slightly OT, but I was in Rome a few weekends ago (to watch England vs Italy Rugby match) and we tried to get train tickets from the airport to the City ... The automatic machine we were using froze and then gave us the Blue Screen of Death It then rebooted itself and up came OS2 Warp V3 ( ... I think it was V3 ... ( a few sherberts had been consumed on the plane !! .. :-) ) ... IIRC, it wasn't called Warp until v4.. -jc- -- 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: More calumny: Secret Service Uses 1980s Mainframe
John, I had heart bypass...what's your excuse? :-) You remember incorrectly, unless this Wiki entry is wrong: http://en.wikipedia.org/wiki/OS/2 Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chase, John Sent: Tuesday, March 02, 2010 7:51 AM To: IBM-MAIN@bama.ua.edu Subject: Re: More calumny: Secret Service Uses 1980s Mainframe -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Nuttall Slightly OT, but I was in Rome a few weekends ago (to watch England vs Italy Rugby match) and we tried to get train tickets from the airport to the City ... The automatic machine we were using froze and then gave us the Blue Screen of Death It then rebooted itself and up came OS2 Warp V3 ( ... I think it was V3 ... ( a few sherberts had been consumed on the plane !! .. :-) ) ... IIRC, it wasn't called Warp until v4.. -jc- -- 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 -- 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: COBOL question. SELECT options vs OPEN
-Original Message- From: IBM Mainframe Discussion List On Behalf Of McKown, John Almost every VSAM file SELECT we have is coded as below: SELECT HISTORY-FILE ASSIGN TO GCR05KSD RECORD KEY IS HST05-KEY ORGANIZATION IS INDEXED ACCESS IS DYNAMIC FILE STATUS IS HISTORY-STATUS. That is, with ACCESS IS DYNAMIC. This despite the fact that the file is opened only once, for INPUT: OPEN INPUT HISTORY-FILE. I'm concerned that this results in less efficient I/O. In particular, that it results in more CPU usage than if the ACCESS were changed from DYNAMIC to SEQUENTIAL. The READ is of the form: READ HISTORY-FILE NEXT RECORD INTO HISTORY-RECORD AT END MOVE 'Y' TO HISTORY-FILE-EOF-SW. From what I can tell, sometime in the past, some programming manager made ACCESS IS DYNAMIC a required standard for all VSAM files. I guess for flexibility. Does this make any significant difference in terms of CPU usage at all? A long time ago (OS/VS COBOL) ACCESS DYNAMIC was considerably more expensive than ACCESS SEQUENTIAL for a VSAM dataset that was processed sequentially; I guess because of (lack of proper) default VSAM buffering. Nowadays I don't get much chance to notice, because the vast majority of our application code is DB2-based rather than VSAM-based. -jc- -- 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: More calumny: Secret Service Uses 1980s Mainframe
Richards, Robert B. pisze: John, I had heart bypass...what's your excuse? :-) You remember incorrectly, unless this Wiki entry is wrong: http://en.wikipedia.org/wiki/OS/2 AFAIR Warp was used for v3. However I absolutely don't remember any BLUE screen on OS/2, except some screensaver. I saw several times crashed OS/2, but no blue screen. Did I miss something? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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
Redirecting CEEDUMP output in Infoprint Server
We are running z/OS V1.9. From what I’m reading in the Infoprint manuals it looks like this can be done. We mostly use afp to pcl transforms but we also have transforms for afp to ps, and afp to pdf in our /etc/Printsrv/aopxfd.conf file. The Infoprint Server Messages and Diagnosis manual (G544-5747-09 section 2.1.4) shows that CEEDUMPS will be written to your .profile or /etc/profile, the dataset indicated in the STDENV DD statement of the AOPBATCH JCL procedure, or the transform configuration file (aopxfd.conf). The manual also talks about PDF to AFP and PS 2 AFP (neither of which we do currently). We have a file pointed at by STDENV in our AOPSTART proc (which executes AOPBATCH) which contains one record: TZ=CST6CDT 1) I’m wondering if I can just add _CEE_DMPTARG as the next record in the STDENV file that would look like this: _CEE_DMPTARG=/my/dumpdir 2) If the new directory I’m using to hold CEEDUMPs fills up what would happen to Infoprint? Would Infoprint components hang up, completely fail, or what might happen? We would monitor this directory with the FSFULL parm on the mount command but if we don’t react fast enough or too many dumps are produced and the directory fills up what might we expect? Thanks in advance for any assistance you can provide in this matter. -- 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: Dallas support (was: Item on TPF)
I agree with Jantje. We've found the ISV support at Dallas to be exceptionally good. They provide first-rate support at an incredible value. -- 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: Redirecting CEEDUMP output in Infoprint Server
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Rick Stetser Sent: Tuesday, March 02, 2010 8:12 AM To: IBM-MAIN@bama.ua.edu Subject: Redirecting CEEDUMP output in Infoprint Server We are running z/OS V1.9. From what I'm reading in the Infoprint manuals it looks like this can be done. We mostly use afp to pcl transforms but we also have transforms for afp to ps, and afp to pdf in our /etc/Printsrv/aopxfd.conf file. The Infoprint Server Messages and Diagnosis manual (G544-5747-09 section 2.1.4) shows that CEEDUMPS will be written to your .profile or /etc/profile, the dataset indicated in the STDENV DD statement of the AOPBATCH JCL procedure, or the transform configuration file (aopxfd.conf). The manual also talks about PDF to AFP and PS 2 AFP (neither of which we do currently). We have a file pointed at by STDENV in our AOPSTART proc (which executes AOPBATCH) which contains one record: TZ=CST6CDT 1)I'm wondering if I can just add _CEE_DMPTARG as the next record in the STDENV file that would look like this: _CEE_DMPTARG=/my/dumpdir 2)If the new directory I'm using to hold CEEDUMPs fills up what would happen to Infoprint? Would Infoprint components hang up, completely fail, or what might happen? We would monitor this directory with the FSFULL parm on the mount command but if we don't react fast enough or too many dumps are produced and the directory fills up what might we expect? Thanks in advance for any assistance you can provide in this matter. In the general case, when a UNIX filesystem fills up, the writes to files in that filesystem get an error return code of ENOSPC (out of space). Now, since this is a dump, I would guess that the dump simply would not get written. But that is a best guess on my part. I would suggest that you make this filesystem be zFS and use the aggrgrow parameter. That way you will get z/OS messages to the z/OS console (where automation can trap them). These are similar to: IOEZ00068E zFS file system Name exceeds Threshold% full (blocks1/blocks2)(WARNING) -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
HDD failure and remote copy
One observed the following event: Hard disk failed in a dasd box (EMC DMX3). Obviously no data was lost, because it was part of RAID group, so the array took spare disk and rebuilt the RAID group. The array is connected to another one using SRDF/S. During the rebuild process some invalid tracks appeared (SQ command showed it). That means some of data was not sent to secondary array. That means that during RAID rebuild data are not synchronously replicated! Q1: Is it normal behavior? Q2: What about other vendors? Does IBM or HDS (or STK/Sun/Oracle) freeze remote replication process during the time of RAID reconstruction process? Does HDD failure affect process of (synchronous) TrueCopy or PPRC ? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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: need for SmartUser?
On 1 Mar 2010 13:07:29 -0800, in bit.listserv.ibm-main you wrote: On 3/1/2010 2:24 PM, Bill Fairchild wrote: The flip side of this coin is that we who build the technical guts of products all too easily can become arrogant. If there weren't dumb end users, we developers would have much smaller incomes. Several years ago I worked for an ISV whose most valuable employee worked in the Quality Assurance group. She had a knack for trying things none of us had ever thought of, and she was the major reason the software shipped nearly bulletproof. Back when I was doing systems programming, we had one user who would find holes in our stuff just playing around to get better ways of doing things AND tell us he had found them. If possible we made sure he was one of our beta testers. Years before that when he was working in customer service, he had crashed our online billing program by placing an order for 9 million airport runway lamps. At 1500 dollars apiece no one would ever buy that many at one time. It caused a multiply error because the result field wasn't big enough. He did this as a part of his general technique to find out how much inventory of a given type of lamp (light bulb to those not in the industry) any warehouse had when his warehouse didn't have enough to ship all of the lamps in one order and no warehouse ever had 9 million lamps of one type at a time. Placing the order gave him a list of what was in all of the other warehouses so he could see if he could force an order that would fill the customer request. Users are using the computer to get the job done and believe (probably rightly in most cases) that they have enough to do to keep up with the arcanities of their field without having to really understand our arcanities and ways of doing things. 30 character error messages can be cryptic as can 80 character messages. How many of us have complained about some of the MVS error messages or COBOL error messages. As to Ted's comments about teachers - my college had this notion that all science and math majors should have some exposure to liberal arts, and made me take a music course, among others. In a report I misspelled primeval, and the professor gave me a B. When I protested, he explained that he expects reports to be written in English, otherwise he couldn't read them and had to award an F. 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 -- 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
Reason for condition code checking being the way it is was Re: Item on TPF
On 1 Mar 2010 17:23:07 -0800, in bit.listserv.ibm-main you wrote: I guess I should note that I am speaking only as an application developer. So I come at it from a different perspective than most of those on this list. But a few things I miss from VSE: - Superior JCL symbolics. - System level symbolics availble for use in batch JCL. - JCL DATE card to override system date. - Return code checking that actually makes sense (can anyone give a good reason for how COND works?). My theory is it was designed by engineers who were used to dealing with not and and not or gates so the negative way of thinking was natural. As someone who has had to do cute things with condition codes I share your disdain. - LIBDEF statements for setting/overriding a library search chain. - JCL symbolics available to batch FTP client. - JCL (JECL) FNO parm for setting FORMDEF/PAGEDEF/FORMS/etc. by specifying a single name. Those are what I can think of offhand. I notice that all of my beefs with z/OS have to do with JCL. Interesting; I'd never really thought about it in that context. Frank -- 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: SHAREWARE at Its Finest
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. jim.marsh...@opm.gov (Jim Marshall) writes: I have been following some discussions on Adventure, StarTrek, and other games around back in the 20th Century. If you look on the CBT tape you will find a number of Computer games from back in the 1970s; WUMPUS, RoadRace, Eliza, Lunar Lander, etc. Thought it was about time to clue folks in on some events. Back in the 1970s the Air Force assigned me to the Pentagon to work on an IBM 360-75J OS/MVT/HASPIII. Along the way we were blessed with the first IBM 303X shipped; namely a 3032 serial number 6. Along with it came all the DASD and tape plus an IBM 3850 MSS (35GB) with a bunch of Virtual IBM 3330 (100MB) drives. re: http://www.garlic.com/~lynn/2010e.html#27 SHAREWARE at Its Finest http://www.garlic.com/~lynn/2010e.html#30 SHAREWARE at Its Finest old email about AFDS looking at getting a couple hundred vm/4341s (each about thruput of 360/75). http://www.garlic.com/~lynn/2001m.html#email790404 in this post: http://www.garlic.com/~lynn/2001m.html#15 departmental servers other old email mentioning vm/43xx machines http://www.garlic.com/~lynn/lhwemail.html#43xx I had sponsored Col. Boyd's briefings at IBM ... misc. past posts mentioning Boyd http://www.garlic.com/~lynn/subboyd.html he had references to doing stint in 1970 running spook base. One of his biographices make reference to his stint at spook base ... with comment that it was a $2.5B windfall for IBM. recent post reference the disk division had datacenter in bldg.26 running numerous MVS machines ... however, it ran out of space for all the computing demand for all the tools. vm/4341s were starting to go into every nookcranny ... w/o needing all the datacenter infrastructure required by the big iron. they started looking at doing something similar with mvs on 4341 ... however, one of the issues when looking at capacity planning was the low capture ratio that really messed up their numbers (MVS and VTAM pathlength by itself would nearly consume the 4341). http://www.garlic.com/~lynn/2010d.html#66 LPARs: More or Less? Part of the problem was that the applications were using some MVS system services not supported by CMS (CMS having about 64kbytes of o/s simulation code). However, Los Gatos lab found that with about another 12kbytes of o/s simulation glue code ... these large applications moved over. -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- 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: More calumny: Secret Service Uses 1980s Mainframe
There are actually sites still running 4381's and MVS/XA. I converted two of them (MVS/XA and MVS/ESA) over to a z/9 and z/10 just last year and we have been contacted by sites still running 967x's and Multiprise systems that have yet to convert. I would be interested in getting some of this old hardware* that still is running, or even dead and pushed into the corner of the data center. So, listmembers, if you have an old 43x1 with 3380s and other 80s era stuff like this, please don't call the scrapper yet! And of course older stuff as well is always welcome. * and docs and software, of course, which eventually gets to Al at bitsavers and CHM. -- Will -- 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: Mixed case to a CLIST from ISPF command line?
Well, we could beat this to death forever. Obviously Windows has a split function just like ISPF -- except that it is much more flexible and supports an unlimited number of splits rather than one. I think you could excuse any shortcoming using your logic. Suppose DD DSN= only supported 32-character dataset names. One could excuse this behavior with IBM was kind enough to give us the DD statement. It was never intended for datasets with long names ... If IBM is going to provide UNIX file support from within ISPF (and they do) then the TSO command ought to accommodate them, IMHO. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dave Salt Sent: Monday, March 01, 2010 9:46 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mixed case to a CLIST from ISPF command line? In Windows, it's easy enough to open a command window (or several) while editing a file (or several) with WordPad without disrupting one's edit session(s) and Copy and Paste among the WordPad and command windows. Isn't this the same as splitting the screen and going into ISPF option 6? In other words, you don't have to disrupt whatever session you happen to be in, and can have a command window where TSO commands can be entered? -- 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: Mixed case to a CLIST from ISPF command line?
Here's an interesting observation. The ISPF Edit Entry Panel (what I have been calling the edit file name panel) supports UNIX mixed-case file names in the Other ... file field. So ISPF is clearly not converting everything to upper case. Yet tso foo bar on the Command=== prompt produces upper case output. Not quite sure how to fit that into the order of upper casing/command recognition detective work. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dave Salt Sent: Monday, March 01, 2010 9:46 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mixed case to a CLIST from ISPF command line? When a command is entered on a command line, ISPF checks to see if the command is recognized as an ISPF command. If it is (for example, if it's SPLIT, SWAP, HELP, TSO, etc) then ISPF processes the command and the underlying dialog (e.g. the ISPF panel) is completely unaware a command was even entered. If the command isn't recognized by ISPF (e.g. if a user enters DOG, FISH, DOIT, etc) the command is passed through to the dialog. The dialog can then process the command, or reject it if the command is unknown. Suppose 'TsO' is entered on a command line that has (or defaults) to CAPS(ON). I'm guessing (but not 100% sure) that the panel attributes cause the command to be uppercased to 'TSO' even *before* the data stream is sent to the mainframe for processing. If this is true, it means even ISPF itself has no idea what was actually entered on the command line, and therefore has no possible opportunity to preserve the original case of the command. If this assumption is wrong I'd think it would be fairly easy for ISPF to preserve the original case of the command. But as this isn't being done, I have to conclude that the order of processing is something like this: 1) A user enters a command on a command line and presses an interrupt key (e.g. ENTER). 2) The data on the panel is pre-processed by the terminal (or emulator) based on the attributes of the panel; e.g. if the command line is defined as (or defaults) to CAPS(ON), the command is converted to uppercase. 3) The data stream is then sent to the mainframe, where it is inspected by ISPF. 4) ISPF converts the first 'word' of the command to uppercase (just in case it was entered on a command line that isn't defined as CAPS(ON)). 5) If the command is recognized by ISPF (e.g. SPLIT,SWAP, HELP, TSO, etc) then it's processed by ISPF. Otherwise, ISPF passes the command through to the underlying dialog (e.g. the procedure that displayed the ISPF panel). I don't know anything about data streams and how they're passed back and forth between terminals and the mainframe, but it would certainly be interesting if someone on this list could confirm whether commands are converted to uppercase before they're sent to the mainframe? In other words, if step 2 above is incorrect and no conversion takes place prior to the data stream being sent to the mainframe, then maybe there is an opportunity for ISPF to preserve the original case of the TSO command? -- 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: Mixed case to a CLIST from ISPF command line?
To help clarify (I hope), The commands that ISPF recognized (TSO, SPLIT, etc.) are not coded in an ISPF program/load module somewhere - they are in a command table. You can modify the one included with ISPF, create your own, etc. Typically in a panel definition the command line is defined with an _ (pre- defined as in input field with CAPS(ON)), but that can be changed by a panel developer. The ISPF panel i...@prim as shipped uses hex 26 for the command field, and defines it as 'TYPE(NEF) CAPS(ON) PADC(USER)'. I changed it on my main menu so I can support lower case. I did this, not for TSO commands, but for my own ISPF commands which allow access to unix paths. To allow this, I changed the CAPS(ON) to CAPS(OFF), and added a command to uppercase a copy of the command ONLY for the purpose of selecting a menu option. This allows such things as selecting option X (exit) from the menu without regard to case. Note that commands in the command table do _not_ require this - that is, I have no special code to handle commands like 'TSO' - ISPF recognizes the command 'tso listalc' or 'TSO listalc' just fine. It also recognizes 'vw /.some_unix_file' where VW is defined in a command table and /.some_unix_file is a unix file name requireing lower case characters. While I recognize that this cannot be done generically by the ISPF developers for _every_ panel (specifically, the ones that they do not code), it would be nice if panel developers (all of them) would provide for lower case as it becomes more commonly required. The SDSF main menu does not react to my tinkering so kindly. Hmm... I wonder if ISPF could consider the CAPS(ON) to only hold for data passed to the dialog itself. That is, ISPF could display and process the panel as if CAPS(OFF) were coded, but if the data in the field must be passed to the dialog, translate it to upper case. If so, my previous statement might not hold. On Tue, 2 Mar 2010 07:43:14 -0800, Charles Mills charl...@mcn.org wrote: Here's an interesting observation. The ISPF Edit Entry Panel (what I have been calling the edit file name panel) supports UNIX mixed-case file names in the Other ... file field. So ISPF is clearly not converting everything to upper case. Yet tso foo bar on the Command=== prompt produces upper case output. Not quite sure how to fit that into the order of upper casing/command recognition detective work. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dave Salt Sent: Monday, March 01, 2010 9:46 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mixed case to a CLIST from ISPF command line? When a command is entered on a command line, ISPF checks to see if the command is recognized as an ISPF command. If it is (for example, if it's SPLIT, SWAP, HELP, TSO, etc) then ISPF processes the command and the underlying dialog (e.g. the ISPF panel) is completely unaware a command was even entered. If the command isn't recognized by ISPF (e.g. if a user enters DOG, FISH, DOIT, etc) the command is passed through to the dialog. The dialog can then process the command, or reject it if the command is unknown. Suppose 'TsO' is entered on a command line that has (or defaults) to CAPS(ON). I'm guessing (but not 100% sure) that the panel attributes cause the command to be uppercased to 'TSO' even *before* the data stream is sent to the mainframe for processing. If this is true, it means even ISPF itself has no idea what was actually entered on the command line, and therefore has no possible opportunity to preserve the original case of the command. If this assumption is wrong I'd think it would be fairly easy for ISPF to preserve the original case of the command. But as this isn't being done, I have to conclude that the order of processing is something like this: 1) A user enters a command on a command line and presses an interrupt key (e.g. ENTER). 2) The data on the panel is pre-processed by the terminal (or emulator) based on the attributes of the panel; e.g. if the command line is defined as (or defaults) to CAPS(ON), the command is converted to uppercase. 3) The data stream is then sent to the mainframe, where it is inspected by ISPF. 4) ISPF converts the first 'word' of the command to uppercase (just in case it was entered on a command line that isn't defined as CAPS(ON)). 5) If the command is recognized by ISPF (e.g. SPLIT,SWAP, HELP, TSO, etc) then it's processed by ISPF. Otherwise, ISPF passes the command through to the underlying dialog (e.g. the procedure that displayed the ISPF panel). I don't know anything about data streams and how they're passed back and forth between terminals and the mainframe, but it would certainly be interesting if someone on this list could confirm whether commands are converted to uppercase before they're sent to the mainframe? In other words, if step 2 above is incorrect and no conversion takes place prior to the data stream being sent to the
Re: OT: need for SmartUser?
On 1 Mar 2010 07:28:07 -0800, in bit.listserv.ibm-main you wrote: Fast food restaurant chains have a lot of experience with successfully dumbing down the keyboard of their cash registers. You might try contacting the chief architect of cash register design for McDonald's: http://www.mcdonalds.com/contact/contact_us.html Perhaps someday a keyboard RPQ attachment will have a mechanical arm that emerges which holds a two-by-four that then smacks the dumb user up beside the head while the monitor displays a forefinger waving from side to side with a loud NO! NO! NO! aural reinforcement. But dumb users would then use all their intelligence to figure out how to disable the RPQ. I have somewhat more sympathy for the user. Most users have enough to do keeping track of their primary job - web design, accounting, etc. than to try to understand baffling messages. There are many error messages that are good but we all have seen the error message that doesn't quite say what happened when read by experts in the area let alone anyone else. Also to be informed of a condition doesn't tell anyone what to do when you get it. Sometimes the response is obvious but there are many messages that are the equivalent of call your systems programmer which are really helpful when you are the systems programmer. A tax accountant has enough problems keeping up with the tax code (regardless of country) and trying to figure out what it means and how it applies to a given situation. Understanding or even being able to communicate some of the error messages may be difficult to impossible for someone not into the arcanity of our field. For the much maligned McDonalds employee, they are supposed to do things quickly and given the desire to have as large a labor pool as possible, using technology to minimize the effort and time of figuring out the charges makes sense. With the turnover many franchises have, minimizing training makes sense. In many cases things are dumbed down so that others can be concentrated on. I use a tax program (actually 1 for Canada and 1 for the US) so that I can be insulated from a lot of the arcanity and concentrate on getting the data right and making the decisions that can't be left to a program. I know that I won't be a happy camper if I get an error message that doesn't give me a clue as to what to do about it. I might add that I am not a happy camper with some of the data entry provisions of either of the two I use and they seem to be the best of a fair-to-middling lot. The mainframe in my experience has its fair share of confusing and unhelpful error messages and warnings that serve little purpose. Bill Fairchild Software Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 Email: bi...@mainstar.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of McKown, John Sent: Monday, March 01, 2010 8:23 AM To: IBM-MAIN@bama.ua.edu Subject: OT: need for SmartUser? This is not really about IBM mainframes. But it is, in a sense, about computing in general. And, perhaps, why mainframes are viewed as archaic. This is a slashdot article. The person appears to be asking a serious question. But, how stupid should computer users be allowed to become? quote The longer I do desktop support, the more it becomes obvious that my users don't read anything that appears on their screen. Instead, they memorize a series of buttons to press to get whatever result they want and if anything unexpected happens, they're completely lost. Error logs help a lot, but they have their limits. I've been toying with a few ideas, but I don't know if any of them will work and I was hoping my fellow Slashdotters could point me in the right direction. For example, I was thinking about creating icons or logos to identify specific errors. They might not remember that an error about uninitialized data but they might be more able to remember that they got the puppy error if I showed a puppy picture next to the error message. Or for times when finding images is too time consuming, you could create simple logos from letters, numbers, symbols, colors or shapes, so you could have the red 5 error or blue square error (or any combination of those elemen! t! s). I've even wondered if it would be possible to expand that to cover the other senses, for example, playing a unique sound with the error. Unfortunately, haptic and olfactory feedback aren't readily available. I like to think that my users would remember the error that caused them to get a swift kick in the balls. And if they forgot it anyhow, I could always help them reproduce it. Does anyone else have experience with ideas like these? Did it work? /quote John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817)
Re: Need tool to zap core
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. Anne Lynn Wheeler l...@garlic.com writes: from long ago and far away (mentions dumprx, vm370 rel6 sepp, and the 3090 service processor): Date: 31 October 1986, 16:32:58 EST To: wheeler Re: 3090/3092 Processor Controll and plea for help re: http://www.garlic.com/~lynn/2010e.html#email861031 in http://www.garlic.com/~lynn/2010e.html#32 Need tool to zap core funny thing about the wording in the above email was that neither the person writing the email nor his immediate management seemed to have realized that I had helped the manager that started the vm service processor for 3090 (i.e. turnover and/or transient nature of the positions). the issue with the 3081 service processor was that a whole bunch of stuff had to be created from scratch (roll-your-own operation). recent post mentioning 3081 service processor http://www.garlic.com/~lynn/2010d.html#43 What was old is new again (water chilled) the trade-off was having a more sophisticated environment for service processor operation but having to invent/develop everything from scratch ... vis-a-vis having an off-the-shelf more sophisticated infrastructure that might possibly have some things that weren't absolutely required. 3090 service processor was getting to the point where it wasn't practical to be inventing/developing everything from scratch. one of the funnies in the 3081 service processor was that its disk drive was 3310 FBA (versus the 3370 FBA used by vm for 3090) ... and the 3081 service processor needed to do paging operations. the 3081 didn't have enough storage for all the microcode ... so there were some 3081 operations that involved the service processor doing microcode paging from the 3310 FBA device. the 3090 engineers would point out that some performance differences between 3081 and 3090 ... was there weren't any critical performance paths that required paging microcode. -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- 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: Mixed case to a CLIST from ISPF command line?
I know next to nothing about ISPF panel development. Would you and/or the assembled crowd guess that modifying the ISPF panel definitions was a reasonable way to proceed? If I could support passing lower-case strings to a Rexx CLIST exec from (1) the main menu panel and (2) from the Edit Entry Panel I think I would be a happy camper. Level set: I am the only developer using this machine. I have total RACF control. The ISPF panels *may* be on read-only volumes as this is an IBM Dallas VM guest. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Robert Birdsall Sent: Tuesday, March 02, 2010 8:32 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mixed case to a CLIST from ISPF command line? To help clarify (I hope), The commands that ISPF recognized (TSO, SPLIT, etc.) are not coded in an ISPF program/load module somewhere - they are in a command table. You can modify the one included with ISPF, create your own, etc. Typically in a panel definition the command line is defined with an _ (pre- defined as in input field with CAPS(ON)), but that can be changed by a panel developer. The ISPF panel i...@prim as shipped uses hex 26 for the command field, and defines it as 'TYPE(NEF) CAPS(ON) PADC(USER)'. I changed it on my main menu so I can support lower case. I did this, not for TSO commands, but for my own ISPF commands which allow access to unix paths. To allow this, I changed the CAPS(ON) to CAPS(OFF), and added a command to uppercase a copy of the command ONLY for the purpose of selecting a menu option. This allows such things as selecting option X (exit) from the menu without regard to case. Note that commands in the command table do _not_ require this - that is, I have no special code to handle commands like 'TSO' - ISPF recognizes the command 'tso listalc' or 'TSO listalc' just fine. It also recognizes 'vw /.some_unix_file' where VW is defined in a command table and /.some_unix_file is a unix file name requireing lower case characters. While I recognize that this cannot be done generically by the ISPF developers for _every_ panel (specifically, the ones that they do not code), it would be nice if panel developers (all of them) would provide for lower case as it becomes more commonly required. The SDSF main menu does not react to my tinkering so kindly. Hmm... I wonder if ISPF could consider the CAPS(ON) to only hold for data passed to the dialog itself. That is, ISPF could display and process the panel as if CAPS(OFF) were coded, but if the data in the field must be passed to the dialog, translate it to upper case. If so, my previous statement might not hold. -- 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: Mixed case to a CLIST from ISPF command line?
Charles, This is what I have done on my Dallas guest: Find the 'VENDOR.ISPPLIB'. Copy the panel(s) you want to change from their original home and modify them in the VENDOR.ISPPLIB library, which, of course, is concatenated first. Charles Mills wrote: I know next to nothing about ISPF panel development. Would you and/or the assembled crowd guess that modifying the ISPF panel definitions was a reasonable way to proceed? If I could support passing lower-case strings to a Rexx CLIST exec from (1) the main menu panel and (2) from the Edit Entry Panel I think I would be a happy camper. Level set: I am the only developer using this machine. I have total RACF control. The ISPF panels *may* be on read-only volumes as this is an IBM Dallas VM guest. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Robert Birdsall Sent: Tuesday, March 02, 2010 8:32 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mixed case to a CLIST from ISPF command line? To help clarify (I hope), The commands that ISPF recognized (TSO, SPLIT, etc.) are not coded in an ISPF program/load module somewhere - they are in a command table. You can modify the one included with ISPF, create your own, etc. Typically in a panel definition the command line is defined with an _ (pre- defined as in input field with CAPS(ON)), but that can be changed by a panel developer. The ISPF panel i...@prim as shipped uses hex 26 for the command field, and defines it as 'TYPE(NEF) CAPS(ON) PADC(USER)'. I changed it on my main menu so I can support lower case. I did this, not for TSO commands, but for my own ISPF commands which allow access to unix paths. To allow this, I changed the CAPS(ON) to CAPS(OFF), and added a command to uppercase a copy of the command ONLY for the purpose of selecting a menu option. This allows such things as selecting option X (exit) from the menu without regard to case. Note that commands in the command table do _not_ require this - that is, I have no special code to handle commands like 'TSO' - ISPF recognizes the command 'tso listalc' or 'TSO listalc' just fine. It also recognizes 'vw /.some_unix_file' where VW is defined in a command table and /.some_unix_file is a unix file name requireing lower case characters. While I recognize that this cannot be done generically by the ISPF developers for _every_ panel (specifically, the ones that they do not code), it would be nice if panel developers (all of them) would provide for lower case as it becomes more commonly required. The SDSF main menu does not react to my tinkering so kindly. Hmm... I wonder if ISPF could consider the CAPS(ON) to only hold for data passed to the dialog itself. That is, ISPF could display and process the panel as if CAPS(OFF) were coded, but if the data in the field must be passed to the dialog, translate it to upper case. If so, my previous statement might not hold. -- 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 -- Axios Products, Inc. supp...@axiosproducts.com 631-864-3666 x133 -- 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: PAGEDEF Coding
When an input record that contains a channel 2 carriage control is read (or when previous input records have been printed with previous PRINTLINEs and this is the next PRINTLINE to be processed), the first data byte (after the carriage control byte) is tested. Since the =x'00' condition is always true, the current COPYGROUP (from the FORMDEF) is used (NULL) for the next page, but the P2 PAGEFORMAT is used to format the next page. See Chapter 6. Conditional Processing in the PPFA book for a more detailed explanation. By the way, the current PPFA book is S544-5284-09. Howard Turetzky Advanced Technical Support InfoPrint Solutions Company Boulder, CO howard.turet...@infoprint.com On Mon, 1 Mar 2010 14:44:58 -0800, George.William william.geo...@ftb.ca.gov wrote: Could someone give me a synopsis of what this block of code does so I can see if I'm starting to understand? PRINTLINE CHANNEL 2; POSITION 10 MM 260 MM COLOR BLUE REPEAT 2; CONDITION PAGE2 START 1 LENGTH 1 WHEN GE X'00' AFTER SUBPAGE NULL PAGEFORMAT PG2; ENDSUBPAGE; PAGEFORMAT PG2; My best guess from a quick read of the manual is; PRINTLINE retrieves and prints the next line from the input data file CHANNEL 2 identifies where the carriage control character is and acts accordingly CONDITION (named PAGE2) checks the first character (for a length of 1) And WHEN it this character is or = to hex '00' it does ... (I sort of lose it here) I guess it does the NULL PAGEFORMAT PG2 AFTER it prints the line??? Thanks for any insights Bill __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- 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 -- 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: Mixed case to a CLIST from ISPF command line?
From: charl...@mcn.org I know next to nothing about ISPF panel development. Would you and/or the assembled crowd guess that modifying the ISPF panel definitions was a reasonable way to proceed? I'd strongly advise against it. First, customizing a panel means you have to remember to reapply the customization each and every time the operating system is upgraded. Second, it would only buy you what you want on a couple of panels and there are hundreds more that would also need to be customized (or where you still couldn't do what you want). Third, there's a reason the panels were defined as CAPS(ON), so changing them to CAPS(OFF) might allow you to do what you want but could potentially cause other things to break. Perhaps a better alternative would be to modify your REXX procedure to check the input argument and see if it's all uppercase. If it is, your REXX procedure could display a message (e.g. You forgot to enter this command on the TSOCMD panel) and then display the TSO command panel so the command can be re-entered? Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html _ Check your Hotmail from your phone. http://go.microsoft.com/?linkid=9712957 -- 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: PAGEDEF Coding
Thanks Howard! -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Howard Turetzky Sent: Tuesday, March 02, 2010 9:12 AM To: IBM-MAIN@bama.ua.edu Subject: Re: PAGEDEF Coding When an input record that contains a channel 2 carriage control is read (or when previous input records have been printed with previous PRINTLINEs and this is the next PRINTLINE to be processed), the first data byte (after the carriage control byte) is tested. Since the =x'00' condition is always true, the current COPYGROUP (from the FORMDEF) is used (NULL) for the next page, but the P2 PAGEFORMAT is used to format the next page. See Chapter 6. Conditional Processing in the PPFA book for a more detailed explanation. By the way, the current PPFA book is S544-5284-09. Howard Turetzky Advanced Technical Support InfoPrint Solutions Company Boulder, CO howard.turet...@infoprint.com __ CONFIDENTIALITY NOTICE: This email from the State of California is for the sole use of the intended recipient and may contain confidential and privileged information. Any unauthorized review or use, including disclosure or distribution, is prohibited. If you are not the intended recipient, please contact the sender and destroy all copies of this email. -- 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: Mixed case to a CLIST from ISPF command line?
From: charl...@mcn.org Here's an interesting observation. The ISPF Edit Entry Panel (what I have been calling the edit file name panel) supports UNIX mixed-case file names in the Other ... file field. So ISPF is clearly not converting everything to upper case. Every field on an ISPF panel is defined using an attribute character. Sometimes a field has it's own unique attribute character, and sometimes several fields all share the same attribute character. For example, perhaps the command line is defined as TYPE(INPUT) COLOR(RED) CAPS(ON) while several output fields are all defined as TYPE(OUTPUT) COLOR(WHITE) CAPS(OFF). So, it's quite possible to have a command line that's defined as or defaults to CAPS(ON) while other fields on the panel are defined as CAPS(OFF). Whether a field is defined as CAPS(ON) or CAPS(OFF) depends on what type of data the dialog developer expects to be entered in the field. Obviously a field that prompts for UNIX file names will be defined as CAPS(OFF), while a command line where commands such as SPLIT, HELP, SWAP (etc) are entered would most likely be defined as CAPS(ON). HTH, Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html _ Take your contacts everywhere http://go.microsoft.com/?linkid=9712959 -- 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
SV: Mixed case to a CLIST from ISPF command line?
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Dave Salt Skickat: den 2 mars 2010 18:27 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Mixed case to a CLIST from ISPF command line? From: charl...@mcn.org snipped Perhaps a better alternative would be to modify your REXX procedure to check the input argument and see if it's all uppercase. If it is, your REXX procedure could display a message (e.g. You forgot to enter this command on the TSOCMD panel) and then display the TSO command panel so the command can be re-entered? Dave Salt Are Your serious ? Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- 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: Mixed case to a CLIST from ISPF command line?
On Tue, 2 Mar 2010 12:27:11 -0500, Dave Salt wrote:
Perhaps a better alternative would be to modify your REXX procedure to check
the input argument and see if it's all uppercase. Wouldn't it be better to
test whether the panel has the CAPS(ON) attribute?
If it is, your REXX procedure could display a message (e.g. You forgot to
enter this command on the TSOCMD panel)
What about intrinsic commands such as ALLOCATE PATH('...')? Wouldn't
he need to front-end all of those?
and then display the TSO command panel so the command can be re-entered?
And if he entered the command arguments, or intends to respond to
prompts by copying and pasting from the text displayed in the panel,
he will have just lost that capability.
Ugh!
It would be better to have a CAPS {OFF|ON} command, available on
every command line, to suspend/override the specification in the
panel definition.
--gil
--
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: Mixed case to a CLIST from ISPF command line?
From: charl...@mcn.org Well, we could beat this to death forever. Obviously Windows has a split function just like ISPF -- except that it is much more flexible and supports an unlimited number of splits rather than one. One??? ISPF has supported a default of 8 splits for a very long time, and more can be defined if required. SPLIT NEW and SWAP NEXT swap between multiple split screens. I think you could excuse any shortcoming using your logic. Suppose DD DSN= only supported 32-character dataset names. One could excuse this behavior with IBM was kind enough to give us the DD statement. It was never intended for datasets with long names ... In the place where I grew up a red traffic light meant STOP. It was illegal to turn left or right on a red light. When I emigrated I discovered it was legal to turn right on a red light. I was delighted. However, there are a few intersections where turning right on a red light is prohibited. I don't complain about the rare circumstances where I can't turn right, but instead I take delight in all the other circumstances where I can turn right. Just because I can't turn right 100% of the time doesn't mean the system is broken. If it did, the only solution would be to allow people to always turn right (even in dangerous situations), or prohibit people from ever turning right. Neither of these 'solutions' is better than the current system where I can 'usually' turn right. In ISPF, I can 'usually' enter a TSO command on any ISPF panel, and it works. In rare situations (e.g. where the command is too long to fit on the command line or is case sensitive), I have to enter 3 extra characters on the command line; i.e. 'TSOCMD;' (followed by the TSO command) instead of just 'TSO '. I don't see entering 3 extra characters as a very big deal, and I think it's FAR less dangerous than taking the route of customizing panels to accept lowercase characters. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html _ Stay in touch. http://go.microsoft.com/?linkid=9712959 -- 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: Mixed case to a CLIST from ISPF command line?
Perhaps a better alternative would be to modify your REXX procedure to check the input argument and see if it's all uppercase. If it is, your REXX procedure could display a message (e.g. You forgot to enter this command on the TSOCMD panel) and then display the TSO command panel so the command can be re-entered? From: thomas.b...@swedbank.se Are Your serious ? Compared to the only other alternative I've heard so far (i.e. customizing panels), yes, I'm deadly serious. And it would be extremely easy to do. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html _ Stay in touch. http://go.microsoft.com/?linkid=9712959 -- 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: Mixed case to a CLIST from ISPF command line?
I don't agree in that I wouldn't strongly advise against it. I would, however, proceed with caution. If you are going to modify the panels, stick to a small number of panels (preferably one). You will need to repeat the modification each time the panel provider changes the panel they provide. For me, it was easy. We already modify the ISPF Primary Option Menu to give different groups of users different options, so I'm stuck with maintaining those modifications regardless. I only changed the 'Option' field on the menu for the System Programmers, so I would only affect a small number of users (and they would let me know immediately if there was a problem). That particular panel only has 1 field using that attribute character (the x'26'). Typically, menu panels (as defined by ISPF) don't pass data directly to the dialog that displays them via the command or option line. Be wary, though. Not all menus are actually implemented this way. As I stated in my earlier post, SDSF didn't like me tinkering with it. In that case, the 'menu' is not a menu in the ISPF sense. Rather, SDSF displays a normal panel, and the commands are parsed by the program that displays the panel (not the panel and not ISPF). That would make it more tricky to modify 'correctly'. On Tue, 2 Mar 2010 12:27:11 -0500, Dave Salt ds...@hotmail.com wrote: From: charl...@mcn.org I know next to nothing about ISPF panel development. Would you and/or the assembled crowd guess that modifying the ISPF panel definitions was a reasonable way to proceed? I'd strongly advise against it. First, customizing a panel means you have to remember to reapply the customization each and every time the operating system is upgraded. Second, it would only buy you what you want on a couple of panels and there are hundreds more that would also need to be customized (or where you still couldn't do what you want). Third, there's a reason the panels were defined as CAPS(ON), so changing them to CAPS(OFF) might allow you to do what you want but could potentially cause other things to break. Perhaps a better alternative would be to modify your REXX procedure to check the input argument and see if it's all uppercase. If it is, your REXX procedure could display a message (e.g. You forgot to enter this command on the TSOCMD panel) and then display the TSO command panel so the command can be re-entered? Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html -- 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
SV: SV: Mixed case to a CLIST from ISPF command line?
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Dave Salt Skickat: den 2 mars 2010 19:16 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: Mixed case to a CLIST from ISPF command line? Perhaps a better alternative would be to modify your REXX procedure to check the input argument and see if it's all uppercase. If it is, your REXX procedure could display a message (e.g. You forgot to enter this command on the TSOCMD panel) and then display the TSO command panel so the command can be re-entered? From: thomas.b...@swedbank.se Are Your serious ? Compared to the only other alternative I've heard so far (i.e. customizing panels), yes, I'm deadly serious. And it would be extremely easy to do. Dave Salt But think of a everyday, not to say everyminute command where You - as described by You above - have to go through a two-step process ? This would be fully acceptable by old standards, but today the standard of userfriendlyness/effectiveness is on a much higher level - AFAICS. I think the UNIX/LINUX shells is setting the bar now. Of course - You maybe is arguing from a standpoint of a viable solution in a closed or restricted environment (whether by authority or resource means). But I think it still is a hard sell... Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- 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: SV: Mixed case to a CLIST from ISPF command line?
When Charles wants to execute the FOO command, and he isn't sure if the panel he's on converts commands to uppercase, the best solution (IMO) is for him to enter this: === tsocmd;foo bar This is only 3 characters more than entering this: === tso foo bar To me this is simple, elegant, always works, and requires no customization to any ISPF panels. If however he should forget to do the first command and instead enters the second command, FOO would see that BAR is uppercase. In this case, it would display the warning message. In other words, this is meant to be a fail-safe mechanism and not something he'd do every time. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Tue, 2 Mar 2010 19:28:26 +0100 From: thomas.b...@swedbank.se Subject: SV: SV: Mixed case to a CLIST from ISPF command line? To: IBM-MAIN@bama.ua.edu -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Dave Salt Skickat: den 2 mars 2010 19:16 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: Mixed case to a CLIST from ISPF command line? Perhaps a better alternative would be to modify your REXX procedure to check the input argument and see if it's all uppercase. If it is, your REXX procedure could display a message (e.g. You forgot to enter this command on the TSOCMD panel) and then display the TSO command panel so the command can be re-entered? From: thomas.b...@swedbank.se Are Your serious ? Compared to the only other alternative I've heard so far (i.e. customizing panels), yes, I'm deadly serious. And it would be extremely easy to do. Dave Salt But think of a everyday, not to say everyminute command where You - as described by You above - have to go through a two-step process ? This would be fully acceptable by old standards, but today the standard of userfriendlyness/effectiveness is on a much higher level - AFAICS. I think the UNIX/LINUX shells is setting the bar now. Of course - You maybe is arguing from a standpoint of a viable solution in a closed or restricted environment (whether by authority or resource means). But I think it still is a hard sell... Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- 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 _ Stay in touch. http://go.microsoft.com/?linkid=9712959 -- 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: Mixed case to a CLIST from ISPF command line?
Actually, since the command _field_ is CAPS(ON), tsocmd;foo bar will be translated to TSOCMD;FOO BAR _before_ it is processed. At least, this is what my (limited) testing seemed to show. Or perhaps that was meant as a shortcut notation for: === tsocmd === foo bar On Tue, 2 Mar 2010 13:41:23 -0500, Dave Salt ds...@hotmail.com wrote: When Charles wants to execute the FOO command, and he isn't sure if the panel he's on converts commands to uppercase, the best solution (IMO) is for him to enter this: === tsocmd;foo bar This is only 3 characters more than entering this: === tso foo bar To me this is simple, elegant, always works, and requires no customization to any ISPF panels. If however he should forget to do the first command and instead enters the second command, FOO would see that BAR is uppercase. In this case, it would display the warning message. In other words, this is meant to be a fail-safe mechanism and not something he'd do every time. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Tue, 2 Mar 2010 19:28:26 +0100 From: thomas.b...@swedbank.se Subject: SV: SV: Mixed case to a CLIST from ISPF command line? To: IBM-MAIN@bama.ua.edu -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Dave Salt Skickat: den 2 mars 2010 19:16 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: Mixed case to a CLIST from ISPF command line? Perhaps a better alternative would be to modify your REXX procedure to check the input argument and see if it's all uppercase. If it is, your REXX procedure could display a message (e.g. You forgot to enter this command on the TSOCMD panel) and then display the TSO command panel so the command can be re-entered? From: thomas.b...@swedbank.se Are Your serious ? Compared to the only other alternative I've heard so far (i.e. customizing panels), yes, I'm deadly serious. And it would be extremely easy to do. Dave Salt But think of a everyday, not to say everyminute command where You - as described by You above - have to go through a two-step process ? This would be fully acceptable by old standards, but today the standard of userfriendlyness/effectiveness is on a much higher level - AFAICS. I think the UNIX/LINUX shells is setting the bar now. Of course - You maybe is arguing from a standpoint of a viable solution in a closed or restricted environment (whether by authority or resource means). But I think it still is a hard sell... Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- 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 _ Stay in touch. http://go.microsoft.com/?linkid=9712959 -- 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 -- 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: Mixed case to a CLIST from ISPF command line?
I've tried this and if it were me, I wouldn't go for it. TSOCMD;foo bar works, for what is requested, that is, the exec gets bar in lower case and both the say before and after the parse command cause the display of lower case bar, but when the exec ends, which is where I have the problem, I am still sitting on the panel titled ISPF Command Shell. I then have to hit PF3 to return to where I was. I realize this is a nit, but if we don't pick them here, then our users pick them when we implement a get around like this. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Robert Birdsall Sent: Tuesday, March 02, 2010 12:58 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mixed case to a CLIST from ISPF command line? Actually, since the command _field_ is CAPS(ON), tsocmd;foo bar will be translated to TSOCMD;FOO BAR _before_ it is processed. At least, this is what my (limited) testing seemed to show. Or perhaps that was meant as a shortcut notation for: === tsocmd === foo bar On Tue, 2 Mar 2010 13:41:23 -0500, Dave Salt ds...@hotmail.com wrote: When Charles wants to execute the FOO command, and he isn't sure if the panel he's on converts commands to uppercase, the best solution (IMO) is for him to enter this: === tsocmd;foo bar This is only 3 characters more than entering this: === tso foo bar To me this is simple, elegant, always works, and requires no customization to any ISPF panels. If however he should forget to do the first command and instead enters the second command, FOO would see that BAR is uppercase. In this case, it would display the warning message. In other words, this is meant to be a fail-safe mechanism and not something he'd do every time. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Tue, 2 Mar 2010 19:28:26 +0100 From: thomas.b...@swedbank.se Subject: SV: SV: Mixed case to a CLIST from ISPF command line? To: IBM-MAIN@bama.ua.edu -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Dave Salt Skickat: den 2 mars 2010 19:16 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: Mixed case to a CLIST from ISPF command line? Perhaps a better alternative would be to modify your REXX procedure to check the input argument and see if it's all uppercase. If it is, your REXX procedure could display a message (e.g. You forgot to enter this command on the TSOCMD panel) and then display the TSO command panel so the command can be re-entered? From: thomas.b...@swedbank.se Are Your serious ? Compared to the only other alternative I've heard so far (i.e. customizing panels), yes, I'm deadly serious. And it would be extremely easy to do. Dave Salt But think of a everyday, not to say everyminute command where You - as described by You above - have to go through a two-step process ? This would be fully acceptable by old standards, but today the standard of userfriendlyness/effectiveness is on a much higher level - AFAICS. I think the UNIX/LINUX shells is setting the bar now. Of course - You maybe is arguing from a standpoint of a viable solution in a closed or restricted environment (whether by authority or resource means). But I think it still is a hard sell... Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- 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 _ Stay in touch. http://go.microsoft.com/?linkid=9712959 -- 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 -- 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 -- 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
Improving my SMP/E usermod procedure
I visit this every time I do an upgrade. z/OS 1.9 to z/OS 1.11 this time. My current usermods for JES exits look like: Concerns after the usermod :) ++USERMOD(TSTMOD2) REWORK(2010060) . ++VER(Z038) FMID(HJE7760) . ++JCLIN . //ASM EXEC PGM=IEV90 //SYSPUNCH DD DSN=TEMP(TST2JOBC),DISP=(,PASS) //SYSIN DD * ZST2JOBC CSECT $CADDR $CALL ... SPLEVEL SYSSTATE END * //LINKEXEC PGM=IEWL,PARM='LET,LIST,XREF,NCAL,RENT' //SYSLMOD DD DSN=SYS1.SHASLNKE,DISP=SHR //SYSLIN DD * INCLUDE SYSPUNCH(TST2JOBC) NAMEZST2JOBC(R) /* ++SRC(TST2JOBC) DISTLIB(AHASSRC) SYSLIB(SWSUSRC) . TST2JOBC TITLE 'USER EXIT 2 MODULE -- PROLOG (MODULE COMMENT BLOCK)' * WSU z/OS 1.7 Use Vanilla exit 2 from IBM. Actual work done in exit 52 * comments about SCHENV should be discounted .. I have a rexx that pulls data from the 'Macro and Copy Code Source Summary' of an assemble of the source and generates the ++JCLIN. This usermod works (FSVO works) in that it dutifully assembles and links the exit into the desired library, while stashing the full source in the SWSUSRC PDS. When I later put maintenance on, the APPLY CHECK flags when there are macro changes. It doesn't work, in that when I proceed to APPLY maintenance, SMP/E attempts to assemble the ++JCLIN, not the ++SRC. What am I missing? I know one part is I only visit this area once a year or less frequently. More a master of none than a JOAT :( Dave Gibney Information Technology Services Washington State University -- 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: Mixed case to a CLIST from ISPF command line?
Fair enough, but what do you suggest instead? Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Tue, 2 Mar 2010 14:26:35 -0500 From: charles.har...@ca.com Subject: Re: Mixed case to a CLIST from ISPF command line? To: IBM-MAIN@bama.ua.edu I've tried this and if it were me, I wouldn't go for it. TSOCMD;foo bar works, for what is requested, that is, the exec gets bar in lower case and both the say before and after the parse command cause the display of lower case bar, but when the exec ends, which is where I have the problem, I am still sitting on the panel titled ISPF Command Shell. I then have to hit PF3 to return to where I was. I realize this is a nit, but if we don't pick them here, then our users pick them when we implement a get around like this. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Robert Birdsall Sent: Tuesday, March 02, 2010 12:58 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mixed case to a CLIST from ISPF command line? Actually, since the command _field_ is CAPS(ON), tsocmd;foo bar will be translated to TSOCMD;FOO BAR _before_ it is processed. At least, this is what my (limited) testing seemed to show. Or perhaps that was meant as a shortcut notation for: === tsocmd === foo bar On Tue, 2 Mar 2010 13:41:23 -0500, Dave Salt ds...@hotmail.com wrote: When Charles wants to execute the FOO command, and he isn't sure if the panel he's on converts commands to uppercase, the best solution (IMO) is for him to enter this: === tsocmd;foo bar This is only 3 characters more than entering this: === tso foo bar To me this is simple, elegant, always works, and requires no customization to any ISPF panels. If however he should forget to do the first command and instead enters the second command, FOO would see that BAR is uppercase. In this case, it would display the warning message. In other words, this is meant to be a fail-safe mechanism and not something he'd do every time. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Tue, 2 Mar 2010 19:28:26 +0100 From: thomas.b...@swedbank.se Subject: SV: SV: Mixed case to a CLIST from ISPF command line? To: IBM-MAIN@bama.ua.edu -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Dave Salt Skickat: den 2 mars 2010 19:16 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: Mixed case to a CLIST from ISPF command line? Perhaps a better alternative would be to modify your REXX procedure to check the input argument and see if it's all uppercase. If it is, your REXX procedure could display a message (e.g. You forgot to enter this command on the TSOCMD panel) and then display the TSO command panel so the command can be re-entered? From: thomas.b...@swedbank.se Are Your serious ? Compared to the only other alternative I've heard so far (i.e. customizing panels), yes, I'm deadly serious. And it would be extremely easy to do. Dave Salt But think of a everyday, not to say everyminute command where You - as described by You above - have to go through a two-step process ? This would be fully acceptable by old standards, but today the standard of userfriendlyness/effectiveness is on a much higher level - AFAICS. I think the UNIX/LINUX shells is setting the bar now. Of course - You maybe is arguing from a standpoint of a viable solution in a closed or restricted environment (whether by authority or resource means). But I think it still is a hard sell... Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- 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 _ Stay in touch. http://go.microsoft.com/?linkid=9712959 -- 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 -- 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: Mixed case to a CLIST from ISPF command line?
That's the problem. I've fought this battle before and can't figure out the winning move. There's no easy solution. Some are better than others and some are near impossible to do due to policies in effect at one's site, etc. I would really love to see the ISPF tool changed to support lower case. That's work for the people at IBM, though as others have indicated and with whom I agree, it should have been done up front. No one I know lives in a black and white world, there is plenty of color out there, so why are we limited to upper only when we could upper, lower and mixed. I guess the bottom line is that one must chose one's bed and then lie in it. Either one customizes the ISPF panels as needed, or uses the TSOCMD process or invents their own, any way you look at it, someone isn't going to like what you do and someone will end up having to live with it. How's that for sitting on the fence? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dave Salt Sent: Tuesday, March 02, 2010 1:48 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mixed case to a CLIST from ISPF command line? Fair enough, but what do you suggest instead? Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Tue, 2 Mar 2010 14:26:35 -0500 From: charles.har...@ca.com Subject: Re: Mixed case to a CLIST from ISPF command line? To: IBM-MAIN@bama.ua.edu I've tried this and if it were me, I wouldn't go for it. TSOCMD;foo bar works, for what is requested, that is, the exec gets bar in lower case and both the say before and after the parse command cause the display of lower case bar, but when the exec ends, which is where I have the problem, I am still sitting on the panel titled ISPF Command Shell. I then have to hit PF3 to return to where I was. I realize this is a nit, but if we don't pick them here, then our users pick them when we implement a get around like this. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Robert Birdsall Sent: Tuesday, March 02, 2010 12:58 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mixed case to a CLIST from ISPF command line? Actually, since the command _field_ is CAPS(ON), tsocmd;foo bar will be translated to TSOCMD;FOO BAR _before_ it is processed. At least, this is what my (limited) testing seemed to show. Or perhaps that was meant as a shortcut notation for: === tsocmd === foo bar On Tue, 2 Mar 2010 13:41:23 -0500, Dave Salt ds...@hotmail.com wrote: When Charles wants to execute the FOO command, and he isn't sure if the panel he's on converts commands to uppercase, the best solution (IMO) is for him to enter this: === tsocmd;foo bar This is only 3 characters more than entering this: === tso foo bar To me this is simple, elegant, always works, and requires no customization to any ISPF panels. If however he should forget to do the first command and instead enters the second command, FOO would see that BAR is uppercase. In this case, it would display the warning message. In other words, this is meant to be a fail-safe mechanism and not something he'd do every time. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Tue, 2 Mar 2010 19:28:26 +0100 From: thomas.b...@swedbank.se Subject: SV: SV: Mixed case to a CLIST from ISPF command line? To: IBM-MAIN@bama.ua.edu -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] För Dave Salt Skickat: den 2 mars 2010 19:16 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: Mixed case to a CLIST from ISPF command line? Perhaps a better alternative would be to modify your REXX procedure to check the input argument and see if it's all uppercase. If it is, your REXX procedure could display a message (e.g. You forgot to enter this command on the TSOCMD panel) and then display the TSO command panel so the command can be re-entered? From: thomas.b...@swedbank.se Are Your serious ? Compared to the only other alternative I've heard so far (i.e. customizing panels), yes, I'm deadly serious. And it would be extremely easy to do. Dave Salt But think of a everyday, not to say everyminute command where You - as described by You above - have to go through a two-step process ? This would be fully acceptable by old standards, but today the standard of userfriendlyness/effectiveness is on a much higher level - AFAICS. I think the UNIX/LINUX shells is setting the bar now. Of course - You maybe is arguing from a standpoint of a viable solution in a closed or restricted environment (whether by authority or resource means). But I think it still
Re: Improving my SMP/E usermod procedure
If the only purpose of the ASM step is to force a reassembly when one of the used macros is updated by SMPE, I would recommend using the ASSEM operand on the ADD MAC statement processed by the UCLIN command. It would probably take only a very minor modification to your REXX. As it stands, SMPE apparently believes that your inline assembler input is independent of your SRC input and reassembles only the one it thinks was impacted. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave Sent: Tuesday, March 02, 2010 11:33 AM To: IBM-MAIN@bama.ua.edu Subject: Improving my SMP/E usermod procedure I visit this every time I do an upgrade. z/OS 1.9 to z/OS 1.11 this time. My current usermods for JES exits look like: Concerns after the usermod :) ++USERMOD(TSTMOD2) REWORK(2010060) . ++VER(Z038) FMID(HJE7760) . ++JCLIN . //ASM EXEC PGM=IEV90 //SYSPUNCH DD DSN=TEMP(TST2JOBC),DISP=(,PASS) //SYSIN DD * ZST2JOBC CSECT $CADDR $CALL ... SPLEVEL SYSSTATE END * //LINKEXEC PGM=IEWL,PARM='LET,LIST,XREF,NCAL,RENT' //SYSLMOD DD DSN=SYS1.SHASLNKE,DISP=SHR //SYSLIN DD * INCLUDE SYSPUNCH(TST2JOBC) NAMEZST2JOBC(R) /* ++SRC(TST2JOBC) DISTLIB(AHASSRC) SYSLIB(SWSUSRC) . TST2JOBC TITLE 'USER EXIT 2 MODULE -- PROLOG (MODULE COMMENT BLOCK)' * WSU z/OS 1.7 Use Vanilla exit 2 from IBM. Actual work done in exit 52 * comments about SCHENV should be discounted .. I have a rexx that pulls data from the 'Macro and Copy Code Source Summary' of an assemble of the source and generates the ++JCLIN. This usermod works (FSVO works) in that it dutifully assembles and links the exit into the desired library, while stashing the full source in the SWSUSRC PDS. When I later put maintenance on, the APPLY CHECK flags when there are macro changes. It doesn't work, in that when I proceed to APPLY maintenance, SMP/E attempts to assemble the ++JCLIN, not the ++SRC. What am I missing? I know one part is I only visit this area once a year or less frequently. More a master of none than a JOAT :( -- 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: Mixed case to a CLIST from ISPF command line?
How about another approach /* rexx */ Do while Parm = '' | Parm = 'PARM' say 'Enter foo PARM' Parse External Parm End say Parm exit 0 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Dave Salt Sent: Tuesday, March 02, 2010 1:16 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SV: Mixed case to a CLIST from ISPF command line? Perhaps a better alternative would be to modify your REXX procedure to check the input argument and see if it's all uppercase. If it is, your REXX procedure could display a message (e.g. You forgot to enter this command on the TSOCMD panel) and then display the TSO command panel so the command can be re-entered? From: thomas.b...@swedbank.se Are Your serious ? Compared to the only other alternative I've heard so far (i.e. customizing panels), yes, I'm deadly serious. And it would be extremely easy to do. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html _ Stay in touch. http://go.microsoft.com/?linkid=9712959 -- 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 Disclaimer: This e-mail message is intended only for the personal use of the recipient(s) named above. If you are not an intended recipient, you may not review, copy or distribute this message. If you have received this communication in error, please notify us immediately by e-mail and delete the original message. This e-mail expresses views only of the sender, which are not to be attributed to Rite Aid Corporation and may not be copied or distributed without this statement. -- 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: Mixed case to a CLIST from ISPF command line?
On Tue, 2 Mar 2010 15:30:55 -0500, Pete Hartung wrote: How about another approach /* rexx */ Do while Parm = '' | Parm = 'PARM' say 'Enter foo PARM' Parse External Parm End say Parm exit 0 And that introduces two additional transactions, one to enter the Parm and one to clear the funky ***. For the customer, there's no right answer. For IBM, the answer is obvious. When the command is TSO, retrieve the original, unmodified text of the command and issue that to the Command Processor. -- gil -- 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: ServerPac share something amusing
What I included was the whole sequence of SYSIN which looks, to me, as if it does nothing productive. IF there is something more going on than meets the eye, I would very much appreciate an explanation of it. Thanks Tony Harminc t...@harminc.net Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 02/28/2010 07:21 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Expire Date: 03/01/2012 To IBM-MAIN@bama.ua.edu cc Subject Re: ServerPac share something amusing On 28 February 2010 20:52, John Mattson john_matt...@ea.epson.com wrote: Sorry. The first CHANGE PATH switches /Service/ and /, the second changes it right back. Looks like a waste to me, but maybe there is something I am missing. The second may change more than just what the first change changed. Tony H. -- 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 -- 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: ServerPac share something amusing
There was a reply that had the intent correct. Avoiding any /Service/Service entries. What I don't get is why they think there are any in the CSI files they distributed? I don't try to merge the Serverpac zones into any existing zones. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Mattson Sent: Tuesday, March 02, 2010 1:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ServerPac share something amusing What I included was the whole sequence of SYSIN which looks, to me, as if it does nothing productive. IF there is something more going on than meets the eye, I would very much appreciate an explanation of it. Thanks Tony Harminc t...@harminc.net Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 02/28/2010 07:21 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Expire Date: 03/01/2012 To IBM-MAIN@bama.ua.edu cc Subject Re: ServerPac share something amusing On 28 February 2010 20:52, John Mattson john_matt...@ea.epson.com wrote: Sorry. The first CHANGE PATH switches /Service/ and /, the second changes it right back. Looks like a waste to me, but maybe there is something I am missing. The second may change more than just what the first change changed. Tony H. -- 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 -- 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 -- 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: ServerPac share something amusing
Thanks, Rex !!! That makes sense. Appologies to the ServerPac folks, it just looked odd to me. -- 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: Improving my SMP/E usermod procedure
But, it UCLIN isn't part of RECEIVE/APPLY/RESTORE. I think this is possible wholly contained in the usermod, as both JES and SDSF do it. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Schwarz, Barry A Sent: Tuesday, March 02, 2010 12:25 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Improving my SMP/E usermod procedure If the only purpose of the ASM step is to force a reassembly when one of the used macros is updated by SMPE, I would recommend using the ASSEM operand on the ADD MAC statement processed by the UCLIN command. It would probably take only a very minor modification to your REXX. As it stands, SMPE apparently believes that your inline assembler input is independent of your SRC input and reassembles only the one it thinks was impacted. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave Sent: Tuesday, March 02, 2010 11:33 AM To: IBM-MAIN@bama.ua.edu Subject: Improving my SMP/E usermod procedure I visit this every time I do an upgrade. z/OS 1.9 to z/OS 1.11 this time. My current usermods for JES exits look like: Concerns after the usermod :) ++USERMOD(TSTMOD2) REWORK(2010060) . ++VER(Z038) FMID(HJE7760) . ++JCLIN . //ASM EXEC PGM=IEV90 //SYSPUNCH DD DSN=TEMP(TST2JOBC),DISP=(,PASS) //SYSIN DD * ZST2JOBC CSECT $CADDR $CALL ... SPLEVEL SYSSTATE END * //LINKEXEC PGM=IEWL,PARM='LET,LIST,XREF,NCAL,RENT' //SYSLMOD DD DSN=SYS1.SHASLNKE,DISP=SHR //SYSLIN DD * INCLUDE SYSPUNCH(TST2JOBC) NAMEZST2JOBC(R) /* ++SRC(TST2JOBC) DISTLIB(AHASSRC) SYSLIB(SWSUSRC) . TST2JOBC TITLE 'USER EXIT 2 MODULE -- PROLOG (MODULE COMMENT BLOCK)' * WSU z/OS 1.7 Use Vanilla exit 2 from IBM. Actual work done in exit 52 * comments about SCHENV should be discounted .. I have a rexx that pulls data from the 'Macro and Copy Code Source Summary' of an assemble of the source and generates the ++JCLIN. This usermod works (FSVO works) in that it dutifully assembles and links the exit into the desired library, while stashing the full source in the SWSUSRC PDS. When I later put maintenance on, the APPLY CHECK flags when there are macro changes. It doesn't work, in that when I proceed to APPLY maintenance, SMP/E attempts to assemble the ++JCLIN, not the ++SRC. What am I missing? I know one part is I only visit this area once a year or less frequently. More a master of none than a JOAT :( -- 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 -- 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
z9 / z10 instruction speed(s)
There are multiple z9 models. Each model has its own MSU rating, which is basically related to the number of CPs enabled and their speed. Now, I know that all the CPs on all z9 run same hardware speed. So, I'm wondering how they are knee capped? Now, I know that the knee capping is done by loading in a specific MCL. So, I'm thinking that this somehow does something like inserts a wait state during instruction processing. That is, the XYZ instruction on all z9s run in the same amount of time. But there is something extra done at the end of the XYZ instruction which causes a wait before the next instruction is actually executed. Am I on the right track? Or is it done is some other strange manner? John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What was old is new again (water chilled)
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. Anne Lynn Wheeler l...@garlic.com writes: somewhat related other old stuff Date: 02/17/81 11:18:51 From: wheeler re: http://www.garlic.com/~lynn/2010d.html#43 What was old is new again (water chilled) http://www.garlic.com/~lynn/2010d.html#45 What was old is new again (water chilled) http://www.garlic.com/~lynn/2010e.html#28 What was old is new again (water chilled) http://www.garlic.com/~lynn/2010e.html#31 What was old is new again (water chilled) the referenced *VM/SP is waiting for you* t-shirt (in Melinda's history) has a large, dark, ominous looking vulture ... representing VM/SP. VM/SP performance problems weren't solely the 3270 storage subpool problem nor solely the multiprocessors changes ... email on the subject from ten months later ... Date: 12/08/81 07:21:58 From: wheeler re: vm/sp performance; almost all heavily loaded, large systems that have gone to vm/sp that i'm aware of, has experienced system degradation compared to whatever they were running perviously. In most cases they have been able to bring performance up to an acceptable level thru variuous code twiddling. As far as I know nobody has found whatever problems are responsible for the system degradation, that all performance improvements would have been equally applicable to whatever level of the system they were running previously (i.e. 1) whatever bug(s) are still there and 2) they could have gotten a much better performaning system by making the modifications to a pre-SP level system). ... snip ... ... and http://www.garlic.com/~lynn/2010e.html#30 SHAREWARE at Its Finest Date: 06/17/81 08:16:55 From: wheeler time to switch heads includes complete propogation delay between end of data transfer on previous data block thru all the channel ccw fetches (transferring appropriate data down to the control unit, etc.) and get to the next data transfer ccw before the r/w heads get to the next data block. page format (for cp) of 4k blocks on 3330 track only leaves room for about 100 byte dummy filler records. Now . . . First thing you do in cp is that if you know that you are chaining CCW packages is to eliminate the SET SECTOR from the TIC'ed to ccw packages (by overlaying the set sector with a copy of the seek and tic'ing to the 2nd ccw in the package). Since the rotational delay is minimal, set sector only increase the delay time in the channel for fetching and transferring data. Since the specs. on the 3330 require a dummy filler gap of greater than what is available, IBM code didn't bother to support switching heads on the 3330. Boston Univ. (running on a 145) did some experimenting and found that head switching did in fact work for their machine. About 3 years ago we picked up that code (which includes TEST mode running where hitsmisses are monitored). We found that on our 158 that it was missing 80% of the time. Since our floor system also runs on several GPD machines, we checked its operation on 4341, 3031s, and 3033s. On 4341 it worked fine, on 3031 and 3033 it had the same operating characteristics as 158. I then talked to a customer with a 168 which did some further experimenting for me. He found that it would hit 100% of the time using IBM CDC drives with the expanded filler. He also found that on Memorex drives he could crank the filler record down to 50 bytes and still get 100% hits. The 4341 essentially has the same channel hardware as the 145 (in fact a standard 4341 with minimal microcode changes is used for 3meg. channel testing). The 158 channels are the slowest channels of the 370 line. The similarity between the 158 and the 303x is because of the channel directors. The same channel director hardware is shared across the whole 303x line. A channel director is essentially a stripped down 158 (i.e. 158 integrated channel microcode). Anyway, most of the delay is not in the actual head switching but in all the delays back in the channel to process all the CCWs between the end of the previous data transfer and the start of the next one. I haven't bothered to actually figure out what would be the required filler block using channel directors. Might try at least double and start cutting it back down from there if you get constant hits. ... snip ... note comment in above about 4341 being used for 3mbyte/sec channel testing. the other alternative for retrofitting (3mbyte/sec) 3380s to earlier machines was Calypso speed-matching addition to 3880 controller ... that was basically the start of ECKD ... and long litney of various kinds of emulation to avoid having to move past CKD. misc. past posts mentioning ECKD and/or Calypso: http://www.garlic.com/~lynn/97.html#16 Why Mainframes? http://www.garlic.com/~lynn/2002g.html#13 Secure Device Drivers http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth http://www.garlic.com/~lynn/2003b.html#7 Disk drives as
Re: HDD failure and remote copy
Radoslaw, I can only comment on HDS equipment. For TrueCopy Synchronous this is not normal behavior during dynamic sparing and drive replacement/rebuild. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S. Sent: Tuesday, March 02, 2010 6:43 AM To: IBM-MAIN@bama.ua.edu Subject: [IBM-MAIN] HDD failure and remote copy One observed the following event: Hard disk failed in a dasd box (EMC DMX3). Obviously no data was lost, because it was part of RAID group, so the array took spare disk and rebuilt the RAID group. The array is connected to another one using SRDF/S. During the rebuild process some invalid tracks appeared (SQ command showed it). That means some of data was not sent to secondary array. That means that during RAID rebuild data are not synchronously replicated! Q1: Is it normal behavior? Q2: What about other vendors? Does IBM or HDS (or STK/Sun/Oracle) freeze remote replication process during the time of RAID reconstruction process? Does HDD failure affect process of (synchronous) TrueCopy or PPRC ? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl -- 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: More calumny: Secret Service Uses 1980s Mainframe
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. subject of thread from last year (in this mailing list): Secret Service plans IT reboot http://fcw.com/Articles/2009/10/19/Web-Secret-Service-IT-modernization.aspx from above: According to the RFI, the service's existing IT infrastructure is outdated and at risk of failing. Forty-two mission-oriented applications run on a 1980s IBM mainframe with a 68 percent performance reliability rating, it said. In addition, data systems and IT security don't meet requirements, the service said. ... snip ... misc. past posts in that thread; http://www.garlic.com/~lynn/2009p.html#11 Secret Service plans IT reboot http://www.garlic.com/~lynn/2009p.html#12 Secret Service plans IT reboot http://www.garlic.com/~lynn/2009p.html#13 Secret Service plans IT reboot http://www.garlic.com/~lynn/2009p.html#18 Secret Service plans IT reboot -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 -- 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
SORT question: How to store record count in existing trailer?
I suspect this is a question for Frank Yeager, but if anyone else has done this I'd appreciate the help. Looking at the Smart DFSORT Tricks PDF I see how to sort detail records between a header and a trailer. So far, so good. Now, though, I need to reset the record count in the existing trailer without changing any of the other values in the trailer. The count should be the count of sorted records NOT including the header and trailer records. The count field is 11 bytes unsigned zoned decimal. TIA for any help you can provide. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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: SORT question: How to store record count in existing trailer?
Peter Farley wrote on 03/02/2010 02:30:27 PM: SORT question: How to store record count in existing trailer? I suspect this is a question for Frank Yaeger, but if anyone else has done this I'd appreciate the help. Looking at the Smart DFSORT Tricks PDF I see how to sort detail records between a header and a trailer. So far, so good. Now, though, I need to reset the record count in the existing trailer without changing any of the other values in the trailer. The count should be the count of sorted records NOT including the header and trailer records. The count field is 11 bytes unsigned zoned decimal. Peter, I'd be glad to help you with this, but I need a bit more information. Please show me an example of the records in your input file and what you expect for output. Is there anything that identifies the header and trailer record, or do we just know that the header record is the first record and the trailer record is the last record? What is the RECFM and LRECL of the input file? What is the starting position of the count field in the trailer record? You can e-mail me the answers offline (yae...@us.ibm.com) if you like.? Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ -- 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: z9 / z10 instruction speed(s)
I was told (years ago,different hardware) that the pipeline was filled with the appropriate number of NOPs. Might have just been an engineer finding a convenient explanation for a sysprog though ... I always wondered how that worked across different workloads - with all the smarts built into the hardware to optimize overlapped pipeline stages and branch prediction. No doubt a better answer will arise. Shane ... On Wed, Mar 3rd, 2010 at 8:59 AM, McKown, John john.mck...@healthmarkets.com wrote: There are multiple z9 models. Each model has its own MSU rating, which is basically related to the number of CPs enabled and their speed. Now, I know that all the CPs on all z9 run same hardware speed. So, I'm wondering how they are knee capped? Now, I know that the knee capping is done by loading in a specific MCL. So, I'm thinking that this somehow does something like inserts a wait state during instruction processing. That is, the XYZ instruction on all z9s run in the same amount of time. But there is something extra done at the end of the XYZ instruction which causes a wait before the next instruction is actually executed. Am I on the right track? Or is it done is some other strange manner? -- 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: Improving my SMP/E usermod procedure
Do you have a sample of how either of those functions accomplish this? I would expect them to do it on the ++MAC input which is not a convenient option for you. By virtue of the source included inline, SMPE is building an ASSEM entry for that code. As documented, the GENASM fields being generated for the macros are being associated with that ASSEM entry. I did not find any way to change the behavior to associate them with the SRC entry instead. One obvious solution is to include your real source in the SYSMOD but I don't recommend it. While UCLIN is a separate command, you only need to process it once and you can add the control cards to the set that contains your RECEIVE command. One thing you might try is to delete any existing ASSEM and SRC entries for TST2JOBC (via UCLIN or RESTORE or maybe both) and then rerun your SYSMOD with the SRC preceding the JCLIN. Alternately, break the SYSMOD in two and apply the SRC first and JCLIN second. The intent in both cases is to somehow sync the ASSEM and SRC entries which is obviously not happening now. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave Sent: Tuesday, March 02, 2010 1:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Improving my SMP/E usermod procedure But, it UCLIN isn't part of RECEIVE/APPLY/RESTORE. I think this is possible wholly contained in the usermod, as both JES and SDSF do it. -- 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
O/T IBM ditches more people
Original URL: http://www.theregister.co.uk/2010/03/02/ibm_us_job_cuts/ IBM cuts more than 1,600 US jobs Under the reporting radar By Timothy Prickett Morgan Posted in Servers, 2nd March 2010 16:49 GMT Free whitepaper – Guidelines for specification of data center power density IBMers from a number of different divisions of the IT giant say that the company initiated another round of resource actions on Monday, with somewhere north of 1,600 people estimated to have lost their jobs. The message board at allia...@ibm (http://www.endicottalliance.org/), the local branch of the Communications Workers of America union headquartered in Endicott, New York (where IBM was originally founded nearly 100 years ago), lit up with people saying they'd been laid off starting yesterday morning. -- 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: z9 / z10 instruction speed(s)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of McKown, John Sent: Tuesday, March 02, 2010 3:59 PM To: IBM-MAIN@bama.ua.edu Subject: z9 / z10 instruction speed(s) There are multiple z9 models. Each model has its own MSU rating, which is= basically related to the number of CPs enabled and their speed. Now, I k= now that all the CPs on all z9 run same hardware speed. So, I'm wondering h= ow they are knee capped? Now, I know that the knee capping is done by l= oading in a specific MCL. So, I'm thinking that this somehow does something= like inserts a wait state during instruction processing. That is, the XY= Z instruction on all z9s run in the same amount of time. But there is some= thing extra done at the end of the XYZ instruction which causes a wait b= efore the next instruction is actually executed. Am I on the right track? O= r is it done is some other strange manner? SNIP From somewhere in the hazy past, it had something to do with instruction fetch. So while instruction fetch was being held up for n microcode cycles, the pipe was being filled, effectively, with NOPR instructions. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- 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: z9 / z10 instruction speed(s)
On 2 March 2010 16:59, McKown, John john.mck...@healthmarkets.com wrote: There are multiple z9 models. Each model has its own MSU rating, which is basically related to the number of CPs enabled and their speed. Now, I know that all the CPs on all z9 run same hardware speed. So, I'm wondering how they are knee capped? Now, I know that the knee capping is done by loading in a specific MCL. So, I'm thinking that this somehow does something like inserts a wait state during instruction processing. That is, the XYZ instruction on all z9s run in the same amount of time. But there is something extra done at the end of the XYZ instruction which causes a wait before the next instruction is actually executed. Am I on the right track? Or is it done is some other strange manner? Could be a simple as disabling (or just not using, or flushing) a certain amount of cache. It would be instructive to see how fast a program that stays in one cache line runs on a less-than-full-speed processor. But no doubt as soon as someone figures out how to exploit that, they'll put a stop to it. Tony H. -- 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: Improving my SMP/E usermod procedure
It appears you are correct. While looking closer, I found this in my Installing your Order: Jobs run during production The UCLIN job, ISF.SISFJCL1(ISFISUCL), which causes SMP/E to reassemble SDSF whenever maintenance affects JES2 macros has been run. I guess my direct desire won't happen :( I can build the UCLIN and combine it at RECEIVE or full APPLY. It will take some more thought to figure what to do with RESTORE and REJECT., Thanks for the help. Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Schwarz, Barry A Sent: Tuesday, March 02, 2010 2:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Improving my SMP/E usermod procedure Do you have a sample of how either of those functions accomplish this? I would expect them to do it on the ++MAC input which is not a convenient option for you. By virtue of the source included inline, SMPE is building an ASSEM entry for that code. As documented, the GENASM fields being generated for the macros are being associated with that ASSEM entry. I did not find any way to change the behavior to associate them with the SRC entry instead. One obvious solution is to include your real source in the SYSMOD but I don't recommend it. While UCLIN is a separate command, you only need to process it once and you can add the control cards to the set that contains your RECEIVE command. One thing you might try is to delete any existing ASSEM and SRC entries for TST2JOBC (via UCLIN or RESTORE or maybe both) and then rerun your SYSMOD with the SRC preceding the JCLIN. Alternately, break the SYSMOD in two and apply the SRC first and JCLIN second. The intent in both cases is to somehow sync the ASSEM and SRC entries which is obviously not happening now. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Gibney, Dave Sent: Tuesday, March 02, 2010 1:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Improving my SMP/E usermod procedure But, it UCLIN isn't part of RECEIVE/APPLY/RESTORE. I think this is possible wholly contained in the usermod, as both JES and SDSF do it. -- 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 -- 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: SORT question: How to store record count in existing trailer?
Peter,
I suspect you've gone home for the day and I'll be in a few hours after you
in the morning
(I'm on the West Coast).
So I'll show you some examples of how to do what you want to do with
DFSORT/ICETOOL.
I'm assuming that your input file has RECFM=FB and LRECL=80. If it has
RECFM=VB and/or
a different LRECL, I can show you how to adjust the jobs if you need me to.
Case 1 - Trailer record has an identifier ('T' in position 1)
The input file looks like this:
H HEADER
D RECORD 01
D RECORD 05
D RECORD 02
D RECORD 04
D RECORD 03
T 009
Here's a DFSORT/ICETOOL job to update the trailer count in positions 3-13:.
//S1 EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//IN DD DSN=... input file (FB/80)
//OUT DD DSN=... output file (FB/80)
//TOOLIN DD *...
* Sort data records
DATASORT FROM(IN) TO(OUT) HEADER TRAILER USING(CTL1)
/*
//CTL1CNTL DD *
* Sort statement for data records
SORT FIELDS=(1,20,CH,A)
OUTFIL FNAMES=OUT,
IFOUTLEN=80,
* Put sequence number at end of all records
IFTHEN=(WHEN=INIT,OVERLAY=(81:SEQNUM,11,ZD)),
* Overlay count of data records in trailer
IFTHEN=(WHEN=(1,1,CH,EQ,C'T'),
OVERLAY=(3:81,11,ZD,SUB,+2,TO=ZD,LENGTH=11)))
/*
The output file would be:
H HEADER
D RECORD 01
D RECORD 02
D RECORD 03
D RECORD 04
D RECORD 05
T 005
Case 2 - Trailer record does not have an identifier (it's just the last
record):
The input file looks like this:
2008/03/02
RECORD 01
RECORD 05
RECORD 02
RECORD 04
RECORD 03
009
Here's a DFSORT/ICETOOL job to update the trailer count in positions 1-11:
//S2 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//IN DD DSN=... input file (FB/80)
//SYM DD DSN=S1,UNIT=SYSDA,SPACE=(TRK,(1,1)),DISP=(,PASS)
//T1 DD DSN=T1,UNIT=SYSDA,SPACE=(CYL,(5,5)),DISP=(,PASS))
//SYSIN DD *
OPTION COPY
* Copy input file with sequence numbers at end
OUTFIL FNAMES=T1,OVERLAY=(81:SEQNUM,11,ZD)
* Create DFSORT symbols as follows:
* NEWCT,'nnn' - count of data records
* TRLID,+nnn - count of all records
OUTFIL FNAMES=SYM,REMOVECC,NODETAIL,
TRAILER1=('NEWCT,''',COUNT-2=(M11,LENGTH=11),C,80:X,/,
'TRLID,+',COUNT=(M11,LENGTH=11))
/*
//S2 EXEC PGM=ICETOOL
//SYMNAMES DD DSN=S1,DISP=(OLD,PASS)
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//IN DD DSN=T1,DISP=(OLD,PASS),
//OUT DD DSN=... output file (FB/80))
//TOOLIN DD *...
* Sort data records
DATASORT FROM(IN) TO(OUT) HEADER TRAILER USING(CTL1)
/*
//CTL1CNTL DD *
* Sort statement for data records
SORT FIELDS=(1,20,CH,A)
OUTFIL FNAMES=OUT,
IFOUTLEN=80,
* Overlay count of data records in trailer
* Use TRILD to identify trailer record.
* Use NEWCT to overlay count.
IFTHEN=(WHEN=(81,11,ZD,EQ,TRLID),
OVERLAY=(1:NEWCT))
/*
The output file would be:
2008/03/02
RECORD 01
RECORD 02
RECORD 03
RECORD 04
RECORD 05
005
If you need help adapting one of these jobs to your requirements, let me
know
the relevant details.
Frank Yaeger - DFSORT Development Team (IBM) - yae...@us.ibm.com
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
= DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/
--
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: Improving my SMP/E usermod procedure
From: Gibney, Dave gib...@wsu.edu To: IBM-MAIN@bama.ua.edu Sent: Tue, March 2, 2010 5:40:47 PM Subject: Re: Improving my SMP/E usermod procedure It appears you are correct. While looking closer, I found this in my Installing your Order: Jobs run during production The UCLIN job, ISF.SISFJCL1(ISFISUCL), which causes SMP/E to reassemble SDSF whenever maintenance affects JES2 macros has been run. I guess my direct desire won't happen :( I can build the UCLIN and combine it at RECEIVE or full APPLY. It will take some more thought to figure what to do with RESTORE and REJECT., Thanks for the help. Dave Gibney Information Technology Services Washington State University Dave: Do not feel bad I think most of us have been bitten by this. Of course once bitten it never happens again. A long time ago I was asked to show a rookie sysprog the process of doing an install. I started out slow and simple and realized after two days I was three days behind. Of all times to be asked to do this as I was under the gun to have this new system up in a week. I talked to my boss and he really wanted me to show the new guy. I told my boss it was close to impossible to train and have the system up on the promised date (not my promise of course). He told me to do the best I could but to have the system up by the promised date. I told the rookie sysprog that I had to take over and for him to watch everything I did and only question what he truly did not understand. I told him to call his wife and tell her he wasn't coming home for at least 5 days. He looked at me and he really wasn't happy. I actually worked 20 hour days with about 3 hours off for eating and sleeping. One of the jobs that I ran was the uclin for SDSF and the uclin for ISPF (that was before the time you could have a additional LPALIB list) and then copy of the ISPF members. He stopped me and asked for an explanation. I told him how important it was to keep the two products in sync he wasn't too sure that it was important for some reason but he got the drift that time was of the essence. We were finishing up the install and IPL'd the new system about an hour before the promised time. I walked up to the boss and told him from now on consult me before promising anything like that again. He actually honored that request and from then on I had input to all those types of decisions. His wife was really mad at me ever since then. I could live with that . The install went amazingly well. I had one oops (initiator not being set for the correct default cpu time. ALl in all a success story but after a week the junior sysprog hung on my shoulder for 6 months. There is a side story about the SDSF JJES2 maintenance that occured while I was on vacation and he was actually able to fix the issue (with a little help from IBM). Ed -- 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
Calling JAVA from SAG Natural.
I am looking for a simple way to call a java code from SAG natural from CICS and batch. The natural program may issue touands of calls to this Java code. Is there an efficient way of doing this? The java code doesn't have to run on same address space and can act as a server. Thanks for your ideas Regards, ITschak -- 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
OT: The gaming world has met the date issue and failed
http://kotaku.com/5482328/ps3s-suffering-from-global-lockdown?skyline=trues=i PS3s Suffering From Global Network Lockdown [UPDATE 7] -- 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
