Re: What's driving my temp data sets to Catalog processing?
They are not temporary data sets. They are real data sets, with names deliberately chosen to merely *look* like temporary data sets. As permanent data sets, MVS processing deals with them just like any other permanent data set. I cannot remember exactly why at the moment, but that's how CA-Endevor works. I seem to recall this has something to do with a difference between how JCL / Step Initiation / Allocation deal with an SMS-managed temporary data set, versus facilities available to a process which attempts to simulate JCL via SVC 99, as is done by a processor running in Endevor. I think it was simply not possible, via SVC 99, to get exactly the same behavior for an SMS-managed temporary data set as is done in JCL / step initiation / allocation, and the *pretend* temporary data set name was the solution Endevor picked for this problem. Brian On Tue, 25 Jul 2006 19:03:25 -0500, Tom Rusnak wrote: Hi folks, I was running GTF to trace SVC 26(CATALOG) to try and figure out why my master catalog hit ratio is between 45-55% both with ISC or VLF, but that may be another thread for another day. I noticed quite a few temporary data sets requests in the trace. The majority if not all were coming out of a third party package (CA Endevor). We do manage our temporary data sets thorugh SMS, however I can't seem to create the same situation either with a amp;amp;TEMP data set in JCL, or running IKJEFT01 in batch and using the TSO ALLOC command. When I GTF my job I don't see any of the temporary data sets in the trace. Can anyone tell me under what circumstances SVC 26 will be used for temporary data sets? Here are a couple of GTF entries for anyone game enough to try. The first word of the PLIST varies a bit although 04008101 seems to be quite common and I believe it along with the 08 at offset 16 is simply a Define. Thanks and all the best, Tom SVC. 026 ASCB 00F60E80 CPU. 0001 JOBNAME. DDVEXTSR MODN SVC-RES R15. 849DD038 R0.. PLIST... 04008101 7F53BDE4 0803 DSN/CI.. SYS06206.T133342.RA000.DDVEXTSR.BNDLST VOLIST.. N/A GMT-07/25/2006 03:33:42.146679 LOC-07/25/2006 13:33:42.14 SVC. 026 ASCB 00F60E80 CPU. JOBNAME. DDVEXTSR MODN SVC-RES R15. 849DD038 R0.. 7F53AD28 PLIST... 1150 0099E5E8 009A083E 009A082E 4000 DSN/CI.. SYS06206.T133342.RA000.DDVEXTSR.BNDLST VOLIST.. N/A -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
More IBM Announcements (July 18 and July 25, 2006)
1. I missed this one last week, but it's interesting. Novell SUSE Linux Enterprise Server (SLES), including mainframe Linux, is now available for ordering through IBM: http://www.ibm.com/common/ssi/rep_ca/2/897/ENUS206-172/ENUS206-172.PDF Linux itself is free software, remember. (It's perfectly legal for you to install and run Linux on your mainframe without asking anyone for permission.) You're buying Novell support using an IBM part number, and that might be helpful to some procurement departments. 2. On July 25, 2006, IBM announced Value Unit-based pricing for nearly its entire Passport Advantage (distributed) software portfolio. Details here: http://www.ibm.com/common/ssi/rep_ca/4/897/ENUS206-154/ENUS206-154.PDF This one is quite interesting. IBM now assigns a number (Value Units) to each distributed server processor core. Then software is priced based on the proxy number, not on the number of cores or chips. None of the software pricing changed with this announcement, but in the future it effectively could. Here's how the numbers are assigned today (per core) as the starting baseline: All single core processors: 100 AMD Opteron dual core: 50 Intel Xenon dual core: 50 IBM POWER5 dual core: 100 HP PA-RISC dual core: 100 Sun UltraSPARC IV dual core: 100 IBM PowerPC dual core: 50 IBM POWER5 QCM dual core: 50 Sun UltraSPARC T1 quad/hexa/octi core: 30 Intel Itanium dual core: 100 IBM System z IFL or engine: 100 Everything else: 100 As you can see, with 100 Value Units = 1 old processor license, i.e. each Value Unit = 1% of the processor license price, none of the pricing changed today. That's very good news for System z IFLs, I'd say. (Some people have expressed fear that IBM would come to its senses with IFL software pricing. It has. No change. Keep enjoying.) One possible side effect is that, at least in the future, software pricing should tend to reward code efficiency and virtualization and make even more costly huge numbers of non-virtualized distributed servers. Unlike some other software vendors there's no cap on the number of virtualized servers that you can run -- virtualization is moot in terms of IBM software licensing costs. Considering that IBM has really, really good virtualization technologies (IFLs being the pinnacle in the non-z/OS world), this makes perfect sense. I suppose this is also good for the planet, (more electricity for your servers and you'll probably pay more for software, too). This is actually a simpler pricing schedule than before because it eliminates some wacky fractional licenses, especially for Sun, that were painful to track for everyone involved. I guess you could say that even Intel processors now get MSU ratings, more or less. We live in interesting times. As a reminder, I don't speak for IBM. Which should be obvious by now. :-) - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries Tokyo (Serving IBM Japan and IBM Asia-Pacific) E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OpenSSH installaion question - Setuid Failing
Hi, The issue was caused by the userid not having read to BPX.DAEMON on the paricular machine I was now testing on. One should never assume! Thank you to those who replied on and off the list. Terry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HSM Tape Utilisation
On Tue, 25 Jul 2006 10:47:52 -0400, O'Brien, David W. (NIH/CIT) [C]
[EMAIL PROTECTED] wrote:
Is this what you had in mind?
LIST TTOC SELECT(BACKUP) ODS('$DOB.TTOC.BKP.JUL25A')
That will do nicely. Thank you, sorry I forgot the basics.
Dave
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DFHSM Shutdown Restart
I would just do a F HSM,STOP and then start it again afterwards but you can change nearly all the parameters dynamically without needing a restart; this not only allows you to 'suck it and see' first but also increases your uptime. You don't say what the parameter was but you can do F HSM,SETSYS parameter (and most other commands like ADDVOL, AUTH etc) anytime and as many times you like, then 'harden' it in the ARCCMDxx member for the next restart once you've definitely decided on that setting. Brian -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Howard Rifkind Sent: 25 July 2006 20:58 To: IBM-MAIN@BAMA.UA.EDU Subject: DFHSM Shutdown Restart Hello, I have to change the HSM starting parmlib member and I don't (can't) re IPL the system. Can anyone help me out with the commands to first stop HSM, shut it down and then restarte it again... Thanks. This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/OS RACF / LDAP Interoperability
Pete Zerger wrote: In perusing some of the docomentation from my first question, I want to pose another: While password synchronization is possible between RACF and 3rd party directory services, is it possible to bypass such mechanisms and connect systems via a trust between two Kerberos realms? And then grant rights to foreign security principals from trusted realms within RACF? Specifically, I am thinking about Active Directory and z/OS 1.7, RACF v2r2, with LDAP and TCP/IP in place on the mainframe side.I am trying to assist in identifying a strategy that moves our organization in the direction of Enterprise single sign-on, while minimizing the use of intermediary products that add cost and complexity unnecessarily. It is certainly possible to use a trust relationship between AD and a KDC on z/OS for a single sign-on solution. You should be aware though that the number of products, daemons, and services on z/OS with Kerberos support is rather limited. -- Ulrich Boche SVA GmbH, Germany IBM Premier Business Partner -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Associated Press: 540,000 New Yorkers at Risk of Identity Theft
Ed Finnell wrote: In a message dated 7/25/2006 10:47:08 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Who??? Even the baby z is a monster! According to the System z9 No, no I was thinking of the single frame z/890. The masters power lifters can do(exceed) that in the three categories. Squat, deadlift and bench press. Gentlemen, What are we talking about ??? Is mainframe more secure because it is heavy ??? What about PC ballasted with some lead slabs, or simply welded to building construction ? Isn't it senseless to discuss mainframe heavy weight as platform advantage ? Even PC can be connected to heavy DASD box, and z/OS can be run on notebook (FlexES or Hercules). I always thought that mainframe is more secure because of z/OS good design, RACF existence and proper administration done by wise guys. The only physical aspect of mainframe security is lack of USB ports. It is much easier to carry out 540.000 records on USB in your pocket (or even *ss) than record data on mainframe-attached tape. However nowadays almost everybody accesses mainframe through terminal emulator on ...PC, which is equipped with USB port. My $0.02 -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Upgrading from OS/390 v2.10 to z/OS 1.7
Hi, We are in the final stages of our upgrade project. The powers that be want to know if anyone has performed such an upgrade? Were there any significant problems? Are there any known bug is z/OS 1.7 that we should look out for? Our current environment is: Two z890's. Each has a production LPAR and a system test LPAR. The production LPAR's are connected in a basic SYSPLEX using CTC's. Software running is OS/390 v2.10, CICS TS 1.3, ADABAS and NATURAL. TIA Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Blocksize and speed limit on an FICON channel
Ron and Jenny Hawkins wrote: Radoslaw, The real bottleneck would be your source media speed. It will be DASD, won't it ? DASD is much SLOWER then tape, when considering sustained sequential I/O's. This has not been true for a long time. Pre-fetching concurrently of 4 or 8 drives is much faster than a single tape drive can handle. There would have to be some serious backend contention problems for tape to be faster than multiple disks. Ron, That's contrary to my experience. Maybe in laboratory conditions, the fastest DASD box, without any other workload could work faster, but I never observed it in real world. Jaguars are really fast. Typically for tapes, it can be observed on long runs. Sprint is still DASD domain. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Upgrading from OS/390 v2.10 to z/OS 1.7
גדי בן אבי wrote: Hi, We are in the final stages of our upgrade project. The powers that be want to know if anyone has performed such an upgrade? Were there any significant problems? Are there any known bug is z/OS 1.7 that we should look out for? Our current environment is: Two z890's. Each has a production LPAR and a system test LPAR. The production LPAR's are connected in a basic SYSPLEX using CTC's. Software running is OS/390 v2.10, CICS TS 1.3, ADABAS and NATURAL. It is unsupported upgrade, so you have to pay special attention to operational datasets upgrade/conversion/use. I mean RACF db, ICF BCSes, HSM, RMM CDSes, JES spool and checkpoint, etc. etc. Theoretically you could re-create them from scratch, but in real world you would want to use existing ones. It can be risky. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Upgrading from OS/390 v2.10 to z/OS 1.7
While I haven't done this type of an upgrade, the major issue to consider is that OS/390 2.10 and z/OS 1.7 cannot coexist in the same SYSPLEX or JES2 spool, so you will need to ugrade both TEST members the same time, then once everything is verified, upgrade the production members. You will also need to work with all your vendors, as you may have to upgrade many of your ISV products, some of which may not be able to ensure that the version you are running will work on z/OS 1.7 and/or if the currently supported version will run on OS/390 2.10. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of ??? ?? ??? Sent: Wednesday, July 26, 2006 5:52 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Upgrading from OS/390 v2.10 to z/OS 1.7 Hi, We are in the final stages of our upgrade project. The powers that be want to know if anyone has performed such an upgrade? Were there any significant problems? Are there any known bug is z/OS 1.7 that we should look out for? Our current environment is: Two z890's. Each has a production LPAR and a system test LPAR. The production LPAR's are connected in a basic SYSPLEX using CTC's. Software running is OS/390 v2.10, CICS TS 1.3, ADABAS and NATURAL. TIA Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Upgrading from OS/390 v2.10 to z/OS 1.7
I know it's risky. RACF copies just fine. Catalogs are OK. We currently assume it will be a one way operation. Once the catalog is used on z/OS 1.7 it will be unusable on OS/390. We will use OFFLOAD to copy the JES SPOOL. Probably also a one way operation. We do not use HSM or RMM. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Wednesday, July 26, 2006 1:19 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Upgrading from OS/390 v2.10 to z/OS 1.7 גדי בן אבי wrote: Hi, We are in the final stages of our upgrade project. The powers that be want to know if anyone has performed such an upgrade? Were there any significant problems? Are there any known bug is z/OS 1.7 that we should look out for? Our current environment is: Two z890's. Each has a production LPAR and a system test LPAR. The production LPAR's are connected in a basic SYSPLEX using CTC's. Software running is OS/390 v2.10, CICS TS 1.3, ADABAS and NATURAL. It is unsupported upgrade, so you have to pay special attention to operational datasets upgrade/conversion/use. I mean RACF db, ICF BCSes, HSM, RMM CDSes, JES spool and checkpoint, etc. etc. Theoretically you could re-create them from scratch, but in real world you would want to use existing ones. It can be risky. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Upgrading from OS/390 v2.10 to z/OS 1.7
The test memner are both already at z/OS 1.7. All ISV products have been installed and tested. We needed to upgrade a few. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Wayne Driscoll Sent: Wednesday, July 26, 2006 1:23 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Upgrading from OS/390 v2.10 to z/OS 1.7 While I haven't done this type of an upgrade, the major issue to consider is that OS/390 2.10 and z/OS 1.7 cannot coexist in the same SYSPLEX or JES2 spool, so you will need to ugrade both TEST members the same time, then once everything is verified, upgrade the production members. You will also need to work with all your vendors, as you may have to upgrade many of your ISV products, some of which may not be able to ensure that the version you are running will work on z/OS 1.7 and/or if the currently supported version will run on OS/390 2.10. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of ??? ?? ??? Sent: Wednesday, July 26, 2006 5:52 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Upgrading from OS/390 v2.10 to z/OS 1.7 Hi, We are in the final stages of our upgrade project. The powers that be want to know if anyone has performed such an upgrade? Were there any significant problems? Are there any known bug is z/OS 1.7 that we should look out for? Our current environment is: Two z890's. Each has a production LPAR and a system test LPAR. The production LPAR's are connected in a basic SYSPLEX using CTC's. Software running is OS/390 v2.10, CICS TS 1.3, ADABAS and NATURAL. TIA Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Upgrading from OS/390 v2.10 to z/OS 1.7
We upgraded to 1.4 from 2.10. We pulled the new 1.4 LPAR out of the PLEX and did the upgrades, etc., there and tested pretty intensely. On the day of the cutover, spool was dumped, RACF backed up, catalogs backed up, etc. WE had applied toleration PTFs to 2.10 but still backed up a lot of stuff just in case. We had a few catalog issues, but after a few days got by them. It was mostly HLQ's getting lost for some odd reason. WE think the person who did the initial catalog work missed a step or two. If you are really unsure, back it all up like you're preparing for a DR because once you get rolling, if you use the same spool space, and so on, you won't be going back. Daniel McLaughlin ZOS Systems Programmer Crawford Company PH: 770 621 3256 * Everything comes to him who hustles while he waits. ? Thomas A. Edison -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Questions on TCB Chain / TIOT
TCBJSTCB DS0A -ADDRESS OF FIRST JOB STEP TCB * OR OF THIS TCB IF KEY ZERO This comment was apparently updated in SP5.1.0 to remove the parenthetical expression (OS/VS2) which I'm guessing was correct (i.e, within OS/VS2, it was the case that this field contained the address of this TCB if key zero; that was before my time). It should have been updated to remove the entire OR phrase. We'll do that in a future release. While we're at it, we'll remove the word first. It is the address of the jobstep TCB for *this* TCB. It is not the address of the first jobstep TCB in the address space (unless this task is the RCT), or necessarily the first jobstep TCB of the initiated/started job. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Upgrading from OS/390 v2.10 to z/OS 1.7
At 06:52 AM 7/26/2006, you wrote: Hi, We are in the final stages of our upgrade project. The powers that be want to know if anyone has performed such an upgrade? Were there any significant problems? Are there any known bug is z/OS 1.7 that we should look out for? Our current environment is: Two z890's. Each has a production LPAR and a system test LPAR. The production LPAR's are connected in a basic SYSPLEX using CTC's. Software running is OS/390 v2.10, CICS TS 1.3, ADABAS and NATURAL. We are z/OS 1.5 running ADABAS and NATURAL. Sorry don't have the versions handy but can get them if you want. We also have z/OS 1.7 in a basic testplex on two boxes. No issues so far. We are moving z/OS 1.7 into one image on the prodplex this weekend. TIA Gadi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Brian W. France Systems Administrator (Mainframe) Pennsylvania State University Administrative Information Services - Infrastructure/Sysarc Rm 25 Shields Bldg., University Park, Pa. 16802 814-863-4739 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: +DFHFC0987 Problem in CICS when access a file.
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Jorge Arueira Campos Hi all I have a problem when CICS acess a file, with the msg below: Anybody please help me in diagnostic of this problem. IEC161I 052(013)-084,CICSEXT0,CICSEXT0,CEXACCTA,,, 01.33.45 STC57935 IEC161I CEX.MZ.ODQ2.MACCTA00.CLUSTER, CEX.MZ.ODQ2.MACCTA00.DATA, 01.33.45 STC57935 IEC161I CATALOG.PRD25 01.33.45 STC57935 +DFHFC0987 PCICSEX0 654 654 Non-RLS OPEN of file CEXACCTA failed: Not available for type of 654 processing. VSAM codes - 0008, 00A8 in module DFHFCFS. Probably you have file CEXACCTA defined with SHR(2,3), another CICS region (or batch job) has the dataset open for input and output, and this CICS region is trying to open it for input and output. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Heads up: zIIP Support incompatibility with CA-OPSMVS TABLE EDIT -FATAL ERROR
Hi, If you are trying to get zIIP support installed as we are you might expect to have to install service to performance reporting tools like TMON, MAINVIEW, in addition to the base z/OS and DB2 support. You might not expect but it looks like this applying JBB772S causes a problem in CA-OPSMVS. We installed JBB772S n/a n/a zIIP Web deliverable -- Installed JBB772S OA15968 UA27115 BCP zIIP Support JBB772S OA16172 UA26410 BCP zIIP Support JBB772S OA16005 UA26753 WLM zIIP Support HRM7720 OA13499 UA90253 RMF zIIP Support HRM7720 OA15453 UA25380 RMF HRM7720 OA14931 UA26170 RMF HQX7720 PK18215 UK14983 SDSF zIIP Support Now the =2.6 TABLE EDIT page gets TABLE EDIT -FATAL ERROR. We have an incident open with CA and understand that other customers have also reported this. Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Alert! IBM APAR OA17290 for FDRABR Users on z/OS V1.7
FDRABR users on z/OS V1.7 and up need to look at IBM HIPER APAR OA17290. It closed on July 24, 2006. Ben Alford Enterprise Systems Programming University of Tennessee -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
snding svc dumps
Let us say you have an svc dump that a vendor needs to debug a prolem. Given that svc dumps can contain sensitive data, in particular likely passwords in a dump generated by an ftp server, I was wondering how other sites typically handle this. -Jeff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ATL Processing with TLMS
We've got the ATL online doing HSM and are getting ready to move our DR backups in as well. We've been going through the CA TLMS books on processing, but still aren't clear on getting the eject portion set up. We're open to more references or even a How To Eject Tapes for Dummies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MD5 for z/OS?
Thanks for the reply. I was just looking for something to verify that a file I uploaded to an HFS had not been corrupted during the transfer. IOW, I was interested in seeing if there was a pre-built program hanging around that I could use. (The file appears to be OK; I was just trying to cover all my bases.) I may take a crack at rolling my own with one of the crypto modules when I get some free time. Jon snip Jon, I assume you're looking for an API to generate MD5 hashes. In that case you'll probably want to look at the cryptographic documentation for z/OS, located here: http://www.ibm.com/servers/eserver/zseries/zos/bkserv/r7pdf/crypto.html /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: looking for an example of RDJFCB in 31 bit
Isn't ARL a feature of RDJFCB? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, July 25, 2006 5:04 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: looking for an example of RDJFCB in 31 bit In [EMAIL PROTECTED] , on 07/24/2006 at 04:49 PM, John J. Leonard [EMAIL PROTECTED] said: I am trying to convert a program to 31 ANY and I am having trouble with an RDJFCB. This might be a good time to switch to using an allocation retrieval list (ARL) instead. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
I don't have this situation - but here are some things I immediately thought of... 1. Change the passwords immediately after creating the dump; 2. If we're talking security-clearance types of issues, then wouldn't the vendor's personnel need a security clearance as well? And shouldn't they be analyzing the dump at your facility then? 3.. Not only the passwords are useful, but also diagnosis of the code and/or data in the dump. may provide information - and there ARE people who can read z/Series instructions straight from a dump. Most experienced sysprogs, in fact, can probably at least recognize LM, L, and ST instructions, especially the sequences used for the beginning and ending of sequences of code where linkage conventions tend to be standardized. So - how do you keep that information from being disclosed? Tim Hare Senior Systems Programmer Florida Department of Transportation (850) 414-4209 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
I believe that IBM has a facility for shipping encrypted dumps. Other vendors need to be able to encrypt also. See the following: The tersed file must be encrypted using the encryption programs, which can be obtained from IBM site: ftp://ftp.emea.ibm.com/pub/mvs/tools/. The instructions are in the file README and a secret key known to IBM and customer. The encrypted file has to be transmitted in binary using an FTP program to a designated IBM FTP Secure server on the Internet. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Horenstein Sent: Wednesday, July 26, 2006 10:02 AM To: IBM-MAIN@BAMA.UA.EDU Subject: snding svc dumps Let us say you have an svc dump that a vendor needs to debug a prolem. Given that svc dumps can contain sensitive data, in particular likely passwords in a dump generated by an ftp server, I was wondering how other sites typically handle this. -Jeff -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What's driving my temp data sets to Catalog processing?
Tom Rusnak [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi folks, I was running GTF to trace SVC 26(CATALOG) to try and figure out why my master catalog hit ratio is between 45-55% both with ISC or VLF, but that may be another thread for another day. I noticed quite a few temporary data sets requests in the trace. The majority if not all were coming out of a third party package (CA Endevor). We do manage our temporary data sets thorugh SMS, however I can't seem to create the same situation either with a amp;TEMP data set in JCL, or running IKJEFT01 in batch and using the TSO ALLOC command. When I GTF my job I don't see any of the temporary data sets in the trace. Can anyone tell me under what circumstances SVC 26 will be used for temporary data sets? Here are a couple of GTF entries for anyone game enough to try. The first word of the PLIST varies a bit although 04008101 seems to be quite common and I believe it along with the 08 at offset 16 is simply a Define. We had an issue a couple of years ago where OEMs were using the services (I believe IGWASMS) to determine if a data set is SMS-managed. Obviously temporary data sets have no aliases, so the master catalog is searched. I would get back to your vendor and ask them to change their code so when a temporary data set name, they NOT call IGWASMS. Thanks, Mark Thomen Catalog/IDCAMS/VSAM Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
Veilleux, Jon L wrote: I believe that IBM has a facility for shipping encrypted dumps. Other vendors need to be able to encrypt also. Secure transportation of the dump is not the issue. His issue is with confidential data in the dump being viewed by the support team trying to solve his problem. Having looked at more than my share of customer dump, I'm interested to hear some of the responses. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MD5 for z/OS?
In a recent note, Jon Brock said: Date: Wed, 26 Jul 2006 10:40:42 -0400 Thanks for the reply. I was just looking for something to verify that a file I uploaded to an HFS had not been corrupted during the transfer. IOW, I was interested in seeing if there was a pre-built program hanging around that I coul d use. (The file appears to be OK; I was just trying to cover all my bases.) I may take a crack at rolling my own with one of the crypto modules when I get some free time. /bin/cksum is of good quality and suitable for everyday (non-cryptographic) use. It's compatible with its brethren on at least Solaris and OS X. Likely a shareware equivalent exists for Windoze. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Wednesday, July 26, 2006 10:17 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: snding svc dumps Veilleux, Jon L wrote: I believe that IBM has a facility for shipping encrypted dumps. Other vendors need to be able to encrypt also. Secure transportation of the dump is not the issue. His issue is with confidential data in the dump being viewed by the support team trying to solve his problem. Having looked at more than my share of customer dump, I'm interested to hear some of the responses. -- Edward E Jaffe And even more for my company - what about HIPAA violations? Or a financial company with PIN numbers and SSNs and credit card numbers? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Mobius View Direct Infopac Storage Creep/Leak - Resolved
FYI - Mobius came up with a fix 'FRCBASLEAK' - Storage leak with multiple VTAM sessions. Fix appears to work and I'm now down to a 'reasonable' 80M working set. -Original Message- Porowski, Ken Anyone out there running Mobius View Direct notice an unusually large working set size? We used to bounce the ViewDirect task each day but stopped a couple of weeks back. Now I notice a gradual increase in the working set between bounces. We will start out around 150M but by the end of the week we are at 350M. No real problem to our system, I'd just like to know if this appears to be 'normal' behavior. Thanks all Ken Porowski AVP Systems Software CIT Group E: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Alert! IBM APAR OA17290 for FDRABR Users on z/OS V1.7
Thanks Ben. This FDRABR customer with an August z/OS 1.7 production implementation planned appreciates the 'heads up'. Just wondering...Did you actually experience the problem or identify the APAR via proactive monitoring of service availability? Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: sending svc dumps
Had an occasion while in the Air Force where one of our programs, running in a secured environment in Europe, crashed and burned. The onsite team sent us the dump, but we had no one on our base cleared to read it! We had to ship it back, take a verbal on symptoms, and re-create the problem in a non-secured system. Then we figured out the fixhad them down for a few days on the process, but it pointed out how real a problem that was, to have to support a TS system with a non-TS staff. Daniel McLaughlin ZOS Systems Programmer Crawford Company PH: 770 621 3256 * Everything comes to him who hustles while he waits. ? Thomas A. Edison -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
Unless you want to run an edit program against the dump then I don't see how you could possibly avoid the vendor seeing the secure data. Our E-Mail system will automatically encrypt any mail that contains 9 digit numbers, maybe some hot shot develpoer could write an interface to ftp to remove or alter any 9 digit number or other specified data in a dump? Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Wednesday, July 26, 2006 11:17 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: snding svc dumps Veilleux, Jon L wrote: I believe that IBM has a facility for shipping encrypted dumps. Other vendors need to be able to encrypt also. Secure transportation of the dump is not the issue. His issue is with confidential data in the dump being viewed by the support team trying to solve his problem. Having looked at more than my share of customer dump, I'm interested to hear some of the responses. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
How could you possibly edit all combinations and not stomp on an instruction or address in some manner? Mind-boggling! ref removal of 9 digit numbers Daniel McLaughlin ZOS Systems Programmer Crawford Company PH: 770 621 3256 * Everything comes to him who hustles while he waits. ? Thomas A. Edison -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
If you sanitize a dump you might find that you have killed information that the support persons might need. Suppose that you are running some product that has an encryption function and it fails. If you sanitize that dump, removing all the clear text, it may become impossible for the support people to figure out what was so special with your data that their code crashed. And if you are taking the IPCS type data (SVC DUMP and / or SYSMDUMP) and sanitizing it, IPCS may not function. That is, the support people may not be able to get IPCS to initialize your dump so that it can be read. Perhaps support contracts need to be reviewed to ensure that both parties (customer and vendor) are doing things that will comply with (whatever alphabet soup you want for secure data legislation that applies on whatever continent you are on/in). Regards, Steve Thompson -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Veilleux, Jon L Sent: Wednesday, July 26, 2006 10:23 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: snding svc dumps Unless you want to run an edit program against the dump then I don't see how you could possibly avoid the vendor seeing the secure data. Our E-Mail system will automatically encrypt any mail that contains 9 digit numbers, maybe some hot shot develpoer could write an interface to ftp to remove or alter any 9 digit number or other specified data in a dump? snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
In the days of paper dumps, the letter agencies used to cut out the sensitive stuff before giving the dumps to IBM. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
OS/390 2.10 architecture level set 1 (and beyond)?
Greetings, Is architecture level set (ALS) 1 required for OS/390 2.10? What machine instructions are required for architecture level set 1, as oppposed to ALS 0? I seem to recall that Perform Locked Operation (PLO) is ALS 1. What are the others? Is there a set of CVT flags for the ALS, or maybe there are bits for individual instructions? Also, is ALS 2 the 64-bit architecture? Is there another ALS for the very recent instructions, like Load And Test (LT) and Load Logical Immediate (LLILF)? thanks in advance ;) Jeffrey D. Smith Farsight Systems Corporation 24 BURLINGTON DR LONGMONT, CO 80501 303-774-9381 direct 303-709-8153 cell 303-484-6170 fax -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Upgrading from OS/390 v2.10 to z/OS 1.7
You have at least one issue. JES2 queue is not compatible between OS/390 2.10 and z/OS 1.7. You need to be at z/OS 1.4 to issue the proper command to upgrade the JES2 spool from 2.10 to 1.4 level. Once the queue is at the 1.4 level, you can then complete your upgrade to 1.7. The proper upgrade path is 2.10 to z/OS 1.4 and then 1.4 to 1.7. גדי בן אבי= wrote: I know it's risky. RACF copies just fine. Catalogs are OK. We currently assume it will be a one way operation. Once the catalog is used on z/OS 1.7 it will be unusable on OS/390. We will use OFFLOAD to copy the JES SPOOL. Probably also a one way operation. We do not use HSM or RMM. Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Wednesday, July 26, 2006 1:19 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Upgrading from OS/390 v2.10 to z/OS 1.7 גדי בן אבי wrote: Hi, We are in the final stages of our upgrade project. The powers that be want to know if anyone has performed such an upgrade? Were there any significant problems? Are there any known bug is z/OS 1.7 that we should look out for? Our current environment is: Two z890's. Each has a production LPAR and a system test LPAR. The production LPAR's are connected in a basic SYSPLEX using CTC's. Software running is OS/390 v2.10, CICS TS 1.3, ADABAS and NATURAL. It is unsupported upgrade, so you have to pay special attention to operational datasets upgrade/conversion/use. I mean RACF db, ICF BCSes, HSM, RMM CDSes, JES spool and checkpoint, etc. etc. Theoretically you could re-create them from scratch, but in real world you would want to use existing ones. It can be risky. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Authorized Command error
I've got an unusual error and the guy that made the changes is on an airplane so I can't call and ask for help, yet. Trying to run a TSO RECEIVE command. Authorized command 'RECEIVE'. Return code = 20. Reason code = 56. ISPD250 Invocation error - System error encountered invoking authorized command 'RECEIVE'. *** RC 20 - IKJEFSTR parameter list contains an error. Reason 56 - The function (either a program or command) is authorized, but a copy of the function could not be found in an authorized library. So far I have done a DDLIST Member RECEIVE Member: RECEIVE STEPLIB SYS1.LINKLIB So the member does exist in SYS1.LINKLIB. SYS1.LINKLIB is in my PROG00 APF ADD DSNAME(SYS1.LINKLIB) VOLUME(ZRES01) LNKLST ADD NAME(LNKLST00) DSN(SYS1.LINKLIB) Mark D Pace Senior Systems Engineer Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 Office: 850.219.5184 Fax: 888.221.9862 http://www.mainline.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Monday blues? (IKJEFTSR RC=20,RSN=40)
On 7/24/2006 3:52 PM, Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of McKown, John Any chance that ISPLLIB (and maybe STEPLIB?) could contain an non-APF authorized library? IIRC, that will remove the APF authorization from all modules loaded via ISPLLIB regardless of the AC value. No //STEPLIB in the logon proc, and about half of //ISPLLIB is unauthorized (and it's always been that way, AFAIK). Besides, if it were an authorization problem I'd expect a different diagnostic than program not found. Of course, this is TSO and ISPF And you also wrote earlier: There are unauthorized libraries in the //ISPLLIB concatenation. But if it's an authorization issue, why does the reason code translate to program not found (reason code 40 (x'28')) instead of something like program not authorized (reason code 56 (x'38'))? First, the flavor of IKJEFTSR that can run code authorized can not find things in ISPLLIB, and has never had the ability to find things there. A form of invocation for IKJEFTSR that would search ISPLLIB exists, but it can not invoke authorized code. Therefore, if this worked previously via IKJEFTSR you must have had another copy of the module somewhere in LINKLIST or LPA, or you must have had a STEPLIB or TSOLIB. As for program not found vs program not authorized I believe you'll find that program not found means exactly that: no copy of the program was found. Program not authorized means, as far as I know, that a copy was found, but not in an authorized library. If IKJEFTSR could search ISPLLIB, and if ISPLLIB contained unauthorized libraries, then I agree that you should have seen a 56 reason code. But as IKJEFTSR can not see ISPLLIB, the 40 was correct. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
One way as a software vendor we deal with this issue (we develop, among other items IMS utilities) is a confidential image copy, in which all of the data is optionally converted to binary zeroes. The customer can then ship the confidential image copy, and we can re-create the problem here with the same version of the code, and the issue vanishes. Re-creation is important to us as we can add it to the regression test suite and validate that the problem has been corrected before shipping customer a fix or work-around. A second method is to place as much information as possible about an abend in the joblog so that the problem can be resolved without the dump. Such items include the usual load module and CSECT name and offset, assembly date and time, maintenance applied, options in effect, etc. This has resulted in faster and more accurate problem diagnosis than the svc dump. A third method is embedded traces which show internal, not customer information, which can be output to SYSOUT data sets. Of course, there will always be the issue that is not resolved by one of these or other similar methods, but they are rare these days. Proactive design of embedded diagnostic tools is a big step forward in avoiding dumps. Tom Harper IMS Utilities Development Team NEON Enterprise Software Steve Thompson wrote: If you sanitize a dump you might find that you have killed information that the support persons might need. Suppose that you are running some product that has an encryption function and it fails. If you sanitize that dump, removing all the clear text, it may become impossible for the support people to figure out what was so special with your data that their code crashed. And if you are taking the IPCS type data (SVC DUMP and / or SYSMDUMP) and sanitizing it, IPCS may not function. That is, the support people may not be able to get IPCS to initialize your dump so that it can be read. Perhaps support contracts need to be reviewed to ensure that both parties (customer and vendor) are doing things that will comply with (whatever alphabet soup you want for secure data legislation that applies on whatever continent you are on/in). Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Alert! IBM APAR OA17290 for FDRABR Users on z/OS V1.7
Ben Alford wrote: FDRABR users on z/OS V1.7 and up need to look at IBM HIPER APAR OA17290. It closed on July 24, 2006. Darn those pesky IBM developers! They just keep allocating new control block bytes from the areas reserved for ISVs! ;-) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
Bob Shannon wrote: In the days of paper dumps, the letter agencies used to cut out the sensitive stuff before giving the dumps to IBM. Some of our super secret customers will provide only snippets from a dump; you have to ask for each and every IPCS command you want issued -- it's a time-consuming process. One such customer takes the dump output and runs it through a filter that changes both hex and character versions of anything that looks the least bit sensitive (userids, system names, job names, etc.) into ''. Looks kinds funny to see '' in the hex portion of a dump! It also makes solving the problem *much* more difficult! Their need for super secrecy is, of course, understandable. They're fighting a war. We do the absolute best we can for them. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OS/390 2.10 architecture level set 1 (and beyond)?
Jeffrey D. Smith wrote: Is architecture level set (ALS) 1 required for OS/390 2.10? What machine instructions are required for architecture level set 1, as oppposed to ALS 0? I seem to recall that Perform Locked Operation (PLO) is ALS 1. What are the others? http://www.ibm.com/servers/s390/os390/plug.html Is there a set of CVT flags for the ALS, or maybe there are bits for individual instructions? CVTH7703 implies ALS 1 is present. Also, is ALS 2 the 64-bit architecture? No. http://www.ibm.com/servers/s390/os390/plug1.html Is there another ALS for the very recent instructions, like Load And Test (LT) and Load Logical Immediate (LLILF)? No. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
More z/OS training roadshows, more on Unicode data
I'm pleased to announce we have scheduled two more z/OS training roadshows: Introduction to z/OS UNIX - Nov. 6-7 You and z/OS and the World Wide Web - Nov. 8-10 details begin here: http://www.trainersfriend.com/Policies/Roadshow_Schedule.htm Remember to get your enrollments in for the September classes: DB2 Version 8 Differences - Sept. 18-19 DB2 Stored Procedures - Sept. 20 Enterprise COBOL Update I: Essentials - Sept. 21 Enterprise COBOL Update II: Unicode and XML Support - Sept. 22 800-993-8716 303-393-8716 For those of you helping with my request for international data in UTF-16, I've put a page on our website that is UTF-16 encoded: http://www.trainersfriend.com/Library/customer.html.ascii The fourth line is the only non-Latin data I have so far (and I created that; the pronounciation is hana bi no hana ya and the translation is Fireworks and Flower Shop). Looking for lots more. Kind regards, -Steve Comstock The Trainer's Friend, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
In a message dated 7/26/2006 10:39:56 A.M. Central Standard Time, [EMAIL PROTECTED] writes: In the days of paper dumps, the letter agencies used to cut out the sensitive stuff before giving the dumps to IBM. There was a big stinko in L.A. branch where it got so bad the IBM PSRs wouldn't read a dump printed from OEM processor. Well when it's your print server it's a problem! Think they finally reconfigured around it but it was PR nightmare for IBM and the customer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
In the days of paper dumps, the letter agencies used to cut out the sensitive stuff before giving the dumps to IBM. That reminds me back in my early days of being a CICS programmer. Our systems programmer couldn't read dumps (don't ask), so when ever CICS dumped she would give me the dumps to read, AFTER she had torn out the pages that had the SNT table in it. HAHAHAHA she spent more time searching for the SNT to tear it out than it took me to find the problems. Mark D Pace Senior Systems Engineer Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 Office: 850.219.5184 Fax: 888.221.9862 http://www.mainline.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Alert! IBM APAR OA17290 for FDRABR Users on z/OS V1.7
Thanks for the info. Liliane At 09:30 AM 7/26/2006, Ben Alford wrote: FDRABR users on z/OS V1.7 and up need to look at IBM HIPER APAR OA17290. It closed on July 24, 2006. Ben Alford Enterprise Systems Programming University of Tennessee Liliane Clever SunGard Higher Education/Temple University Lead Systems Programmer 1-215-204-6411 (Office) ; 1-215-204-1817 (Fax) [EMAIL PROTECTED] ; [EMAIL PROTECTED] www.sungardhe.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
Years ago, a large USA federal law enforcement agency (that goes by a 3 letter acronym) for that reason would not send us SYSMDUMPs, but only paper dumps. Some poor Special Agent had to go through the dump with a permanent black ink marker and go over any identifiable information in the interpreted side. We always felt sorry for whoever that lucky person was, because he was working hard, doing as we were told, not knowing that we tech support people could still figure out what was there by looking at the hex portion. I had a colleague who went on site to a large USA customer whom I can neither confirm or deny, who debugged an installation problem by reading the error messages given to him on a piece of paper by the sergeant assigned to him. It took him about 12 hours before the product was finally installed. But this is a serious issue. I'll bet that there is no provision in (insert random alphabetic characters here) that allows this. Oh, and also, if you haven't thought about it - Windows has its automatic phone home in case of error. Think twice before telling it to send the error report. Later, Ray -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Thompson, Steve (SCI TW) Sent: Wednesday July 26 2006 08:34 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: snding svc dumps If you sanitize a dump you might find that you have killed information that the support persons might need. Suppose that you are running some product that has an encryption function and it fails. If you sanitize that dump, removing all the clear text, it may become impossible for the support people to figure out what was so special with your data that their code crashed. And if you are taking the IPCS type data (SVC DUMP and / or SYSMDUMP) and sanitizing it, IPCS may not function. That is, the support people may not be able to get IPCS to initialize your dump so that it can be read. Perhaps support contracts need to be reviewed to ensure that both parties (customer and vendor) are doing things that will comply with (whatever alphabet soup you want for secure data legislation that applies on whatever continent you are on/in). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What's driving my temp data sets to Catalog processing?
On Wed, 2006-07-26 at 08:15 -0700, Mark Thomen wrote: We had an issue a couple of years ago where OEMs were using the services (I believe IGWASMS) to determine if a data set is SMS-managed. Obviously temporary data sets have no aliases, so the master catalog is searched. I would get back to your vendor and ask them to change their code so when a temporary data set name, they NOT call IGWASMS. Which vendor/product was that, Mark? I also see lots and lots of cache misses against my master as Tom does. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
Our E-Mail system will automatically encrypt any mail that contains 9 digit numbers, maybe some hot shot develpoer could write an interface to ftp to remove or alter any 9 digit number or other specified data in a dump I don't see how you could do this - it's entirely possible for some sequence of constants necessary for debugging to appear to be an n-digit number. Tim Hare Senior Systems Programmer Florida Department of Transportation (850) 414-4209 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Authorized Command error
Opinion 1. SYS1.LINKLIB should never be in the STEPLIB - you run the risk of using incompatible/inconsistent versions of system modules that way 2. Software libraries ought to be found through the catalog /Opinion Tom Conley has great presentations on how to manage your TSO/ISPF environment; if you're going to SHARE see if he's giving one. If not, maybe hire him as a consultant for a while. Tim Hare Senior Systems Programmer Florida Department of Transportation (850) 414-4209 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
On Wed, 26 Jul 2006 11:39:25 -0400, Bob Shannon wrote: In the days of paper dumps, the letter agencies used to cut out the sensitive stuff before giving the dumps to IBM. Bob Shannon Rocket Software Not just IBM. We got more than one dump with 99% of the information redacted. That made it VERY difficult to debug problems. Lloyd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OS/390 2.10 architecture level set 1 (and beyond)?
Where is the Twilight Zone music when you need it? The first URL describes hardware features needed for OS/390 2.10 and says they will be available in Sept 2000. We bought our 2003-106 no later than summer of 98 and it has been running 2.10 for several years now. Did IBM really beat the target data by more than 2 years? -Original Message- From: Edward Jaffe [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 9:04 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: OS/390 2.10 architecture level set 1 (and beyond)? Jeffrey D. Smith wrote: Is architecture level set (ALS) 1 required for OS/390 2.10? What machine instructions are required for architecture level set 1, as oppposed to ALS 0? I seem to recall that Perform Locked Operation (PLO) is ALS 1. What are the others? http://www.ibm.com/servers/s390/os390/plug.html Is there a set of CVT flags for the ALS, or maybe there are bits for individual instructions? CVTH7703 implies ALS 1 is present. Also, is ALS 2 the 64-bit architecture? No. http://www.ibm.com/servers/s390/os390/plug1.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
For us, the vendor must be a party to non disclosure contracts. Even so, we are facing increased requirements that we, in turn, have to pass on the vendor. For example, do we have to insist that the dump be encrypted while stored on the vendor's DASD? How do we know that is happening? If that data is somehow compromised, who takes the beating? While we know a lot of this goes past the point of decreasing return all the way into silliness, we are having to pay the price of cheap PC based solutions and auditors on power trips that either can't tell the difference, don't care, or both. C'mon retirement!! -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Horenstein Sent: Wednesday, July 26, 2006 9:02 AM To: IBM-MAIN@BAMA.UA.EDU Subject: snding svc dumps Let us say you have an svc dump that a vendor needs to debug a prolem. Given that svc dumps can contain sensitive data, in particular likely passwords in a dump generated by an ftp server, I was wondering how other sites typically handle this. -Jeff NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
Looks like we're heading down a whole new SOX road here. I send you a dump, even with a nondisclosure, and it gets compromised, we're both in the soup. I send you a dump on paper and it isn't destroyed after use, same thing. Oh what a tangled web! Daniel McLaughlin ZOS Systems Programmer Crawford Company PH: 770 621 3256 * Everything comes to him who hustles while he waits. ? Thomas A. Edison -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What's driving my temp data sets to Catalog processing?
Brian, I am not sure if this is still relevant, but about 10 years ago we had a vendor who did (probably something like you are doing). After doing some tracing it turns out that if you have the passed dataset indicator on in the dynalloc it causes the issue I think you are seeing. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OS/390 2.10 architecture level set 1 (and beyond)?
So the scheduled for availability phrase applies to 2.10, not the hardware features. I guess I don't read enough announcements to appreciate the nuances of IBM's phrasing. Thanks -Original Message- From: Edward Jaffe [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 11:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: OS/390 2.10 architecture level set 1 (and beyond)? Schwarz, Barry A wrote: Where is the Twilight Zone music when you need it? The first URL describes hardware features needed for OS/390 2.10 and says they will be available in Sept 2000. We bought our 2003-106 no later than summer of 98 and it has been running 2.10 for several years now. Did IBM really beat the target data by more than 2 years? No. They were right on time. The hardware features comprising the ALS were available for many years before the Sep. 2000 availability of OS/390 R10. The ALS was supported all the way back to 9672-G2 and, as you've stated, the old MP2K machines. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Monday blues? (IKJEFTSR RC=20,RSN=40)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Walt Farrell [ snippage ] First, the flavor of IKJEFTSR that can run code authorized can not find things in ISPLLIB, and has never had the ability to find things there. A form of invocation for IKJEFTSR that would search ISPLLIB exists, but it can not invoke authorized code. Therefore, if this worked previously via IKJEFTSR you must have had another copy of the module somewhere in LINKLIST or LPA, or you must have had a STEPLIB or TSOLIB. Discussed this in our staff meeting today, and best I can surmise based on available evidence and documentation, and the means by which we propagate maintenance across the sysplex, this is the most plausible sequence of events: 0. For this illustration let's say we run three z/OS images in a Parallel Sysplex. Let's call them Production, Development and Sandbox. 1. Each z/OS image owns a pair of SYSRES sets; let's call them PRI and ALT. Each dataset that resides in the SYSRES sets has a SYS1 hlq and is indirectly cataloged. 2. We have an installation-defined load library that is both APF-authorized and link-listed; let's call it SYS1.COMPANY.LOADLIB. This load library resides in the SYSRES set on each image. 3. We installed the DocuText product in the Development image, and later propagated it to the Production image. Note that it was never installed into the Sandbox image. 4. In accordance with the product installation doc, we apparently chose the option to copy the D00YAAI authorized load module into each instance of SYS1.COMPANY.LOADLIB on the Development and Production images (but NOT on Sandbox, since we didn't intend to run it there). Everything worked as expected. 5. Priorities got changed, we played some musical chairs, and the official rollout of the product got postponed. 6. In preparation for events occurring now, at least two maintenance cycles were applied to z/OS. Maintenance is initially applied to the ALT RES set on Sandbox, while it is IPLed from its PRI set. Sandbox is then IPLed from its ALT set, and initial smoke-testing of the applied maintenance is done. 7. When we are satisfied that the maintenance didn't break anything, it is propagated to the Development image via full-volume COPY from the Sandbox ALT RES set to the Development ALT RES set (Development is running on its PRI set when this is done). Note that the copy of SYS1.COMPANY.LOADLIB on Development's ALT RES set will NOT contain the D00YAAI load module. Development is then IPLed from its ALT RES set. 8. By this time the official rollout of the DocuText product has fallen off the back burner into the pile of stuff we gotta do when a burner becomes available again. Accordingly, nobody thought to exercise it with the z/OS maintenance. 9. After a suitable shakedown period, the maintenance is propagated to Production via the same technique described in #7. Now another instance of SYS1.COMPANY.LOADLIB is missing the D00YAAI load module. A. After a suitable period of running Production with the maintenance, the decision is made to normalize the RES sets to prepare for the next maintenance cycle. Normalization is done by full-volume copy of each image's ALT RES set to its respective PRI RES set. Each image is subsequently IPLed from its PRI RES set. By this time, there is no longer a copy of SYS1.COMPANY.LOADLIB that contains the D00YAAI load module. B. The time arrived to list all software products we need to migrate to the new infrastructure and test. DocuText was rediscovered, so after verifying that we are current on our DocuText license, I tried to run it. The results of that attempt gave birth to this thread on IBM-MAIN. As for program not found vs program not authorized I believe you'll find that program not found means exactly that: no copy of the program was found. Program not authorized means, as far as I know, that a copy was found, but not in an authorized library. If IKJEFTSR could search ISPLLIB, and if ISPLLIB contained unauthorized libraries, then I agree that you should have seen a 56 reason code. But as IKJEFTSR can not see ISPLLIB, the 40 was correct. I understand now. This illustrates why we generally try to avoid having multiple copies of a load module in different libraries. Thanks, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ATL Processing with TLMS
A new chapter was added recently with the r11.5 version of TLMS. You can download those manuals from SupportConnect, and even if you are still running r11.0 (or even the unsupported R5.5) the documentation will be applicable to you. After reading the new chapter, if you still have a problem please contact CA-Dynam/TLMS support. Russell Witt CA-Dynam/TLMS Level-2 Support Manager -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Daniel A. McLaughlin Sent: Wednesday, July 26, 2006 9:34 AM To: IBM-MAIN@BAMA.UA.EDU Subject: ATL Processing with TLMS We've got the ATL online doing HSM and are getting ready to move our DR backups in as well. We've been going through the CA TLMS books on processing, but still aren't clear on getting the eject portion set up. We're open to more references or even a How To Eject Tapes for Dummies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Blocksize and speed limit on an FICON channel
BTW, check out the restore time from a ExHPDM tape - that can be an eye opener! We worked through the restore issues with ExHPDM when we first incorporated it. Very simply put, its VERY important that the restores run in the same order as the backups and that restore jobs are queued up and waiting to run when a volume's first block of data is found on the steaming tape. Running things out of order does indeed cause extremely slow restore times as, depending on the settings, tapes are either rewinding or skipping over data to get the data needed for restores. Once we had the methodology down we were able to restore our 2.7 TB of data to non-STK disk in less than 5 hours. Remember it was backed up in less than two hours - the restore to non-STK is important to note since this forces our native STK compressed data on the tape to be decompressed by FDR as it does the restores. Jeffrey Deaver, Senior Analyst, Systems Engineering 651-665-4231 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Monday blues? (IKJEFTSR RC=20,RSN=40)
So if you had put the module on your sandbox, then this thread probably would not exist? Don Imbriale On Wed, 26 Jul 2006 14:07:29 -0500, Chase, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Walt Farrell [ snippage ] First, the flavor of IKJEFTSR that can run code authorized can not find things in ISPLLIB, and has never had the ability to find things there. A form of invocation for IKJEFTSR that would search ISPLLIB exists, but it can not invoke authorized code. Therefore, if this worked previously via IKJEFTSR you must have had another copy of the module somewhere in LINKLIST or LPA, or you must have had a STEPLIB or TSOLIB. Discussed this in our staff meeting today, and best I can surmise based on available evidence and documentation, and the means by which we propagate maintenance across the sysplex, this is the most plausible sequence of events: 0. For this illustration let's say we run three z/OS images in a Parallel Sysplex. Let's call them Production, Development and Sandbox. 1. Each z/OS image owns a pair of SYSRES sets; let's call them PRI and ALT. Each dataset that resides in the SYSRES sets has a SYS1 hlq and is indirectly cataloged. 2. We have an installation-defined load library that is both APF-authorized and link-listed; let's call it SYS1.COMPANY.LOADLIB. This load library resides in the SYSRES set on each image. 3. We installed the DocuText product in the Development image, and later propagated it to the Production image. Note that it was never installed into the Sandbox image. 4. In accordance with the product installation doc, we apparently chose the option to copy the D00YAAI authorized load module into each instance of SYS1.COMPANY.LOADLIB on the Development and Production images (but NOT on Sandbox, since we didn't intend to run it there). Everything worked as expected. 5. Priorities got changed, we played some musical chairs, and the official rollout of the product got postponed. 6. In preparation for events occurring now, at least two maintenance cycles were applied to z/OS. Maintenance is initially applied to the ALT RES set on Sandbox, while it is IPLed from its PRI set. Sandbox is then IPLed from its ALT set, and initial smoke-testing of the applied maintenance is done. 7. When we are satisfied that the maintenance didn't break anything, it is propagated to the Development image via full-volume COPY from the Sandbox ALT RES set to the Development ALT RES set (Development is running on its PRI set when this is done). Note that the copy of SYS1.COMPANY.LOADLIB on Development's ALT RES set will NOT contain the D00YAAI load module. Development is then IPLed from its ALT RES set. 8. By this time the official rollout of the DocuText product has fallen off the back burner into the pile of stuff we gotta do when a burner becomes available again. Accordingly, nobody thought to exercise it with the z/OS maintenance. 9. After a suitable shakedown period, the maintenance is propagated to Production via the same technique described in #7. Now another instance of SYS1.COMPANY.LOADLIB is missing the D00YAAI load module. A. After a suitable period of running Production with the maintenance, the decision is made to normalize the RES sets to prepare for the next maintenance cycle. Normalization is done by full-volume copy of each image's ALT RES set to its respective PRI RES set. Each image is subsequently IPLed from its PRI RES set. By this time, there is no longer a copy of SYS1.COMPANY.LOADLIB that contains the D00YAAI load module. B. The time arrived to list all software products we need to migrate to the new infrastructure and test. DocuText was rediscovered, so after verifying that we are current on our DocuText license, I tried to run it. The results of that attempt gave birth to this thread on IBM-MAIN. As for program not found vs program not authorized I believe you'll find that program not found means exactly that: no copy of the program was found. Program not authorized means, as far as I know, that a copy was found, but not in an authorized library. If IKJEFTSR could search ISPLLIB, and if ISPLLIB contained unauthorized libraries, then I agree that you should have seen a 56 reason code. But as IKJEFTSR can not see ISPLLIB, the 40 was correct. I understand now. This illustrates why we generally try to avoid having multiple copies of a load module in different libraries. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Daniel A. McLaughlin Looks like we're heading down a whole new SOX road here. I send you a dump, even with a nondisclosure, and it gets compromised, we're both in the soup. I send you a dump on paper and it isn't destroyed after use, same thing. Oh what a tangled web! Our data is so sensitive, you'll have to come here to diagnose the dump. And after you fix the problem, we'll have to kill you. In fact, we'll have to kill you even if you don't fix the problem! Meanwhile, back in reality, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Monday blues? (IKJEFTSR RC=20,RSN=40)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Imbriale, Don So if you had put the module on your sandbox, then this thread probably would not exist? Probably not. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Associated Press: 540,000 New Yorkers at Risk of Identity Theft
Sadly, I must disagree. The auditors are going to be all over *us* demanding that *we* plug the hole caused by a missing laptop. All we can reasonably do is demand credentials before we let you see the data. But we don't have any realistic way to positively prevent your misuse of that data. Sigh. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Sipples Sent: Tuesday, July 25, 2006 7:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Associated Press: 540,000 New Yorkers at Risk of Identity Theft The IT staff at CS Stars, a Chicago-based independent insurance brokerage, and at the State of New York, decided it was a smart idea to use a personal computer to shuttle data between the State's system and the brokerage's. Then the personal computer, housed in a secured facility (hah), went missing. AP has the story: http://www.msnbc.msn.com/id/14015598/ This incident has absolutely nothing to do with mainframes. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries Tokyo (Serving IBM Japan and IBM Asia-Pacific) E-Mail: [EMAIL PROTECTED] NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Authorized Command error
On Wed, 26 Jul 2006 12:03:04 -0400, Mark Pace [EMAIL PROTECTED] wrote: I found it. Doing a DDLIST again and looking for the steplib I found that the IKJACCNT proc had been changed to SYS1.LINKLIB on a VOLSER in the maintenance volumes. I changed that back to the production VOLSER and it worked fine. ... A TSO logon proc STEPLIBing SYS1.LINKLIB? With a VOLSER? I'm sure there's a reason. Actually, I guess the only reason to STEPLIB to SYS1.LINKLIB would because you NEEDED to point to a different volser. But you post didn't make it sound like this was intentional. Do you know why that(or any) SYS1.LINKLIB is in your STEPLIB concatenation? That sounds to me like a circumvention that was forgotten. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Associated Press: 540,000 New Yorkers at Risk of Identity Theft
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Wednesday, July 26, 2006 2:41 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Associated Press: 540,000 New Yorkers at Risk of Identity Theft Sadly, I must disagree. The auditors are going to be all over *us* demanding that *we* plug the hole caused by a missing laptop. All we can reasonably do is demand credentials before we let you see the data. But we don't have any realistic way to positively prevent your misuse of that data. Sigh. Sounds like the PC in question should have had all sensitive data placed on an encrypted partition / filesystem. I think that Windows allows this. I know that Linux has the ability. I have no idea one way or the other about Mac. Actually, in order to be secure, encrypt the data on the mainframe before shipping it to the laptop. Now refuse to give anybody the key. grin -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Authorized Command error
Mark Pace wrote: Are there other non-authorized libraries concatenated in the STEPLIB with SYS1.LINKLIB? I found it. Doing a DDLIST again and looking for the steplib I found that the IKJACCNT proc had been changed to SYS1.LINKLIB on a VOLSER in the maintenance volumes. I changed that back to the production VOLSER and it worked fine. Why not just remove the gratuitous/erroneous SYS1.LINKLIB reference from STEPLIB? (And, if possible, remove the STEPLIB altogether?) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
Didn't you see the movie Paycheck? RK -Original Message- From: IBM Mainframe Discussion List On Behalf Of Daniel A. McLaughlin Looks like we're heading down a whole new SOX road here. I send you a dump, even with a nondisclosure, and it gets compromised, we're both in the soup. I send you a dump on paper and it isn't destroyed after use, same thing. Oh what a tangled web! Our data is so sensitive, you'll have to come here to diagnose the dump. And after you fix the problem, we'll have to kill you. In fact, we'll have to kill you even if you don't fix the problem! Meanwhile, back in reality, -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Heads Up: OA16005 if you have zIIP support installed
Friends have told me If you have installed the IBM z/OS web deliverable for zIIP support (new FMID JBB77S9 for z/OS 1.6 or FMID JBB772S for z/OS 1.7), you MUST install PTFs for APAR OA16005. I understand that the failure to install OA16005 can result in WAIT08E on multiple LPARs in a parallel sysplex upon implementation of a WLM policy activation command. One of those things where the sysprog hits enter in the WLM ISPF dialog, and all LPARs immediately crash. Sounds like a bad day to me. Ironically, the WAIT08E only happens if your CPU does NOT have a zIIP engine installed. This particular process works correctly if a zIIP exists in the LPAR. Fortunately, this has not happened to me. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Associated Press: 540,000 New Yorkers at Risk of Identity Theft
I wonder if these types of situations will cause the pendulum to swing back more towards roll-your-own software. There has been a slight slowdown of buying canned packages for various reasons because of the hurdles of customizing for one's particular environment or redoing your business processes to fit canned software. Of course, that doesn't help things such as operating systems or TP monitors or databases, but at least if you roll your own applications, debugging remains in house and theoretically under your control - unless you outsource, which is another can of worms... Later, Ray -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Wednesday July 26 2006 12:41 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Associated Press: 540,000 New Yorkers at Risk of Identity Theft Sadly, I must disagree. The auditors are going to be all over *us* demanding that *we* plug the hole caused by a missing laptop. All we can reasonably do is demand credentials before we let you see the data. But we don't have any realistic way to positively prevent your misuse of that data. Sigh. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Sipples Sent: Tuesday, July 25, 2006 7:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Associated Press: 540,000 New Yorkers at Risk of Identity Theft The IT staff at CS Stars, a Chicago-based independent insurance brokerage, and at the State of New York, decided it was a smart idea to use a personal computer to shuttle data between the State's system and the brokerage's. Then the personal computer, housed in a secured facility (hah), went missing. AP has the story: http://www.msnbc.msn.com/id/14015598/ This incident has absolutely nothing to do with mainframes. - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries Tokyo (Serving IBM Japan and IBM Asia-Pacific) E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Associated Press: 540,000 New Yorkers at Risk of Identity Theft
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ray Mullins Sent: Wednesday, July 26, 2006 3:42 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Associated Press: 540,000 New Yorkers at Risk of Identity Theft I wonder if these types of situations will cause the pendulum to swing back more towards roll-your-own software. There has been a slight slowdown of buying canned packages for various reasons because of the hurdles of customizing for one's particular environment or redoing your business processes to fit canned software. This would figure. Our CIO wants to migrate to vendor software instead of our custom, in house written, software. I will grant that he has some good points. Especially the support question. Oh, don't ask why support for in-house written apps is a question. It's embarrassing. snip Later, Ray -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Wednesday July 26 2006 12:41 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Associated Press: 540,000 New Yorkers at Risk of Identity Theft Sadly, I must disagree. The auditors are going to be all over *us* demanding that *we* plug the hole caused by a missing laptop. All we can reasonably do is demand credentials before we let you see the data. But we don't have any realistic way to positively prevent your misuse of that data. Sigh. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OS/390 2.10 architecture level set 1 (and beyond)?
Basically, IBM tries (not always as successfully as some on this list would like) to make hardware advances well ahead of the software that requires them. For example 64 bit hardware was available well before z/OS 1.5 which requires it. The ALS for OS/390 2.10 was also supported in hardware for about 2 years before the release of 2.10. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Schwarz, Barry A Sent: Wednesday, July 26, 2006 1:54 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: OS/390 2.10 architecture level set 1 (and beyond)? So the scheduled for availability phrase applies to 2.10, not the hardware features. I guess I don't read enough announcements to appreciate the nuances of IBM's phrasing. Thanks -Original Message- From: Edward Jaffe [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 11:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: OS/390 2.10 architecture level set 1 (and beyond)? Schwarz, Barry A wrote: Where is the Twilight Zone music when you need it? The first URL describes hardware features needed for OS/390 2.10 and says they will be available in Sept 2000. We bought our 2003-106 no later than summer of 98 and it has been running 2.10 for several years now. Did IBM really beat the target data by more than 2 years? No. They were right on time. The hardware features comprising the ALS were available for many years before the Sep. 2000 availability of OS/390 R10. The ALS was supported all the way back to 9672-G2 and, as you've stated, the old MP2K machines. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Blocksize and speed limit on an FICON channel
This has not been true for a long time. Pre-fetching concurrently of 4 or 8 drives is much faster than a single tape drive can handle. Ron, I agree, but unless you have a product like ExHPDM to write multiple concurrent backups to a single tape, it doesn't help. Dumping 1 disk to 1 tape, or 10 disks to 10 tapes, there seems to always be a tape drive on the market which is faster than fastest available disk. They keep leapfrogging, of course. -- Bruce Black Senior Software Developer Innovation Data Processing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Alert! IBM APAR OA17290 for FDRABR Users on z/OS V1.7
FYI, we are in the process of preparing an email to our FDRABR customers to notify them of this APAR and two child APARs. Note that the PTFs are not yet available but ++APARs are available for two of the APARs. -- Bruce Black Senior Software Developer Innovation Data Processing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
Back in the days of paper dumps, we used to get dumps from certain government agencies with lines carefully blacked out or sometimes even razored out!! These days I think all you can do is to get some management-type to make an intelligent decision weighing the sensitivity of the data vs the need to get the problem solved. Yea, I know that management and intelligent are often incompatible -- Bruce Black Senior Software Developer Innovation Data Processing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
Years ago, a large USA federal law enforcement agency (that goes by a 3 letter acronym) for that reason would not send us SYSMDUMPs, but only paper dumps. Some poor Special Agent had to go through the dump with a permanent black ink marker and go over any identifiable information in the interpreted side Probably the same agency I referred to. Even if you didn't want to interpret the hex, if it was printed on an impact printer you could still usually read the text behind the blackout. . -- Bruce Black Senior Software Developer Innovation Data Processing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ATL Processing with TLMS
We don't use TLMS, we use CA-1, but we modified our CA-1 vault distribution report to help. It's the simplest thing that could possibly work and it hasn't given us any problem We added code to our vault distribution report (an Earl program, may be common to TLMS as well) to create a file of eject commands for our STK robot, and then scheduled a subsequent STK utility to actually issue the commands. The code was originally designed when we had a Memorex ATL and thousands of 3490 cartridges, of which a few hundred were ejected on Mondays after the weekend backups, so it has one additional feature: using logic derived from how we vault the tapes, we calculate a 'return date' for each tape, and we sort the eject commands into order by 'return date' and then volume. This allowed us to group tapes into plastic carrying cases, slap a 'return date' on them, and have people just grab cases to return tapes to the center on that date. It wasn't perfect but worked okay; now, of course, with 9840 cartridges, it's not so useful since they just put all of the tapes into the minimum number of boxes and they have to look through them anyway. I can send a description of, and the code for, our modifications to TMSVLT02 (not sure of the legality of sending the entire program code since the base TMSVLT02 belongs to CA). Tim Hare Senior Systems Programmer Florida Department of Transportation (850) 414-4209 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
Probably - they have a lot of Special Agents. And sometimes you could even read through the permanent marker. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black Sent: Wednesday July 26 2006 14:10 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: snding svc dumps Years ago, a large USA federal law enforcement agency (that goes by a 3 letter acronym) for that reason would not send us SYSMDUMPs, but only paper dumps. Some poor Special Agent had to go through the dump with a permanent black ink marker and go over any identifiable information in the interpreted side Probably the same agency I referred to. Even if you didn't want to interpret the hex, if it was printed on an impact printer you could still usually read the text behind the blackout. . -- Bruce Black Senior Software Developer Innovation Data Processing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads-up: OA17218 Serious problems for dynamic changes to DASD
Thanks. I really hate it when I pull the trigger on a known safe, working process only to find a smoking hole in my foot. :-) Wanna guess what I was just getting ready to do? Yup. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Brian Peterson Sent: Friday, July 14, 2006 6:31 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Heads-up: OA17218 Serious problems for dynamic changes to DASD There apparently is a flaw in the process of changing the SSCB table representing DASD control unit SSIDs. The flaw is exposed when making dynamic configuration changes to DASD devices - specifically, when adding or removing devices from an already online string represented by a particular SSID. The code incorrectly maintains the number of device entries in the SSCB table, and therefore when resizing the SSCB table to accomodate changes in the number of devices in an SSID, can overlay other MVS control blocks. Check out OA17218 for details, as well as a Rube Goldberg-esque workaround to avoid the overlay if you need to make a dynamic configuration change that would result in an overlay. I'd suggest trying to avoid falling into this particular snake pit. The list of additional symptoms sounds nasty to me! Brian NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads-up: OA17218 Serious problems for dynamic changes to DASD
In a message dated 7/26/2006 4:57:05 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Thanks. I really hate it when I pull the trigger on a known safe, working process only to find a smoking hole in my foot. :-) Wanna guess what I was just getting ready to do? Yup. _http://www.talkleft.com/new_archives/010074.html_ (http://www.talkleft.com/new_archives/010074.html) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
On 26 Jul 2006 11:42:37 -0700, in bit.listserv.ibm-main you wrote: For us, the vendor must be a party to non disclosure contracts. Even so, we are facing increased requirements that we, in turn, have to pass on the vendor. For example, do we have to insist that the dump be encrypted while stored on the vendor's DASD? How do we know that is happening? If that data is somehow compromised, who takes the beating? While we know a lot of this goes past the point of decreasing return all the way into silliness, we are having to pay the price of cheap PC based solutions and auditors on power trips that either can't tell the difference, don't care, or both. If the person reading the dump at either end has a PC as opposed to a true 327x, that person can probably get all kinds of information and copy it in interesting ways. C'mon retirement!! -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Jeff Horenstein Sent: Wednesday, July 26, 2006 9:02 AM To: IBM-MAIN@BAMA.UA.EDU Subject: snding svc dumps Let us say you have an svc dump that a vendor needs to debug a prolem. Given that svc dumps can contain sensitive data, in particular likely passwords in a dump generated by an ftp server, I was wondering how other sites typically handle this. -Jeff NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Associated Press: 540,000 New Yorkers at Risk of Identity Theft
Ray Mullins wrote: I wonder if these types of situations will cause the pendulum to swing back more towards roll-your-own software. There has been a slight slowdown of buying canned packages for various reasons because of the hurdles of customizing for one's particular environment or redoing your business processes to fit canned software. In many past cases, management lost faith in their own in-house application developers. They became afraid of not having the best of breed solution, built with best practices methodologies. But the pendulum is swinging back somewhat because people are starting to realize some awful truths: * Many shrink wrapped solutions aren't any better (or cheaper) than what you can produce yourself with competent applications developers. * Outsourcing on the part of the software suppliers has negatively affected the quality of some of these packages. * Worst of all, if you and your competitors all buy the same so-called best of breed package, you've just lost your competitive advantage! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSAM Checker
Mark Steely [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... I have downloaded the VSAM Checker from IBM. This check for IMBED and REPLICATE in VSAM files. On some of the catalogs I am receiving the following message: DATA SET NAME - ATTRIBUTES FOUND - CATALOG.. RECEIVED CATALOG RC: 008 RSN: 042 MODULE ID EG What message ID is this related to? Any help would be appreciated. Most likely you have a user connector in the master catalog but the catalog doesn't exist on the volume it points to. Thanks, Mark Thomen Catalog/IDCAMS/VSAM Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What's driving my temp data sets to Catalog processing?
David Andrews [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Wed, 2006-07-26 at 08:15 -0700, Mark Thomen wrote: We had an issue a couple of years ago where OEMs were using the services (I believe IGWASMS) to determine if a data set is SMS-managed. Obviously temporary data sets have no aliases, so the master catalog is searched. I would get back to your vendor and ask them to change their code so when a temporary data set name, they NOT call IGWASMS. Which vendor/product was that, Mark? I also see lots and lots of cache misses against my master as Tom does. You'll probably have to do a GTF trace to find out who is issuing the calls to Catalog. Or you can just ask the vendors you are using if they call IGWASMS for temporary data sets Thanks, Mark Thomen Catalog/IDCAMS/VSAM Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ARM RESTART MANAGER
-- Forwarded message -- From: Jorge Arueira Campos [EMAIL PROTECTED] Date: Jul 25, 2006 10:40 PM Subject: ARM RESTART MANAGER To: IBM-MAIN@bama.ua.edu Hi Again I need information about ARM Restart. In my shop I codified a policy of restart for my STC's with the only start for products of file transfers. When I IPL the driving system, the restart do not occours in the target system(SSP2), the sample and the syslog below. Anybody have a sample of policy whith rules of restart for only three elements ??? Thanks for all Jorge Arueira Campos/Vanderlei Canesso CEF-OSASCO-SP - BRAZIL DATA TYPE(ARM) DEFINE POLICY NAME(POLARM1) REPLACE(YES) RESTART_ORDER RESTART_GROUP(DEFAULT) ELEMENT(*) RESTART_ATTEMPTS(0) LEVEL(1) ELEMENT_NAME(XFBS1MLB) LEVEL(2) ELEMENT_NAME(XFBS1SRQ) LEVEL(3) ELEMENT_NAME(XFBS1TRN) RESTART_GROUP(XFB) TARGET_SYSTEM(SSP2) ELEMENT(XFBS1MLB) ELEMENT(XFBS1SRQ) ELEMENT(XFBS1TRN) RESTART_METHOD(BOTH,STC,'S XFBS1???') SYSLOG Msg: THE RESTART ATTEMPTS THRESHOLD HAS BEEN REACHED. IXC804I JOBNAME XFBS1SRQ, ELEMENT XXFBXFBS1SRQ WAS NOT RESTARTED. 075 THE RESTART ATTEMPTS THRESHOLD HAS BEEN REACHED. IXC804I JOBNAME XFBS1MLB, ELEMENT XXFBXFBS1MLB WAS NOT RESTARTED. 076 THE RESTART ATTEMPTS THRESHOLD HAS BEEN REACHED. IXC804I JOBNAME XFBS1TRN, ELEMENT XXFBXFBS1TRN WAS NOT RESTARTED. 077 THE RESTART ATTEMPTS THRESHOLD HAS BEEN REACHED. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Natural Error with DB2 Version 8
Has anyone come across a compatibility error with Natural 3.1 and DB2 Version 8 on z/OS 1.4? We recently upgraded to DB2 Version 8 and have found that our Natural Static Bind process is having problems. Well the bind step itself is working just great, but the step after that I believe is a process that modifies a Natural flag so that the module runs Static is failing with the following: STAT9093 Error 1102 occurred in program SGMODB-N on line 1890 SGMODB-N 1890 NAT1102 Input hexadec. Value does not contain hexadec. characters NAT9987 Natural Session Terminated Abnormally - RC=40 Here's the JCL that runs the step: //NATMODF EXEC NATURAL,SYS=DEVD,UNIT=USER, // COND=((8,LT)), // REGION=(3072K) //CMWKF01 DD DSN=DSNHOUT,DISP=(OLD,DELETE) //CMWKF02 DD DSN=TMP7,DISP=(,DELETE), //UNIT=USER, //SPACE=(TRK,(5,5),RLSE), //DCB=(DSORG=PS,RECFM=FB,LRECL=80,BLKSIZE=3120) //CMSYNIN DD * NDEVDEVD,DISCADM %* DISCIS SYSDB2 CMD MODIFY Thanks for looking, -Norm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Natural Error with DB2 Version 8
You might want to ask this on SAG-L. Subscribe at [EMAIL PROTECTED] Best regards, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.mrmullins.big-bear-city.ca.us/ http://www.the-bus-stops-here.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. --ilvi -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hjelm, Norm Sent: Wednesday 26 July 2006 15:57 To: IBM-MAIN@BAMA.UA.EDU Subject: Natural Error with DB2 Version 8 Has anyone come across a compatibility error with Natural 3.1 and DB2 Version 8 on z/OS 1.4? We recently upgraded to DB2 Version 8 and have found that our Natural Static Bind process is having problems. Well the bind step itself is working just great, but the step after that I believe is a process that modifies a Natural flag so that the module runs Static is failing with the following: STAT9093 Error 1102 occurred in program SGMODB-N on line 1890 SGMODB-N 1890 NAT1102 Input hexadec. Value does not contain hexadec. characters NAT9987 Natural Session Terminated Abnormally - RC=40 Here's the JCL that runs the step: //NATMODF EXEC NATURAL,SYS=DEVD,UNIT=USER, // COND=((8,LT)), // REGION=(3072K) //CMWKF01 DD DSN=DSNHOUT,DISP=(OLD,DELETE) //CMWKF02 DD DSN=TMP7,DISP=(,DELETE), //UNIT=USER, //SPACE=(TRK,(5,5),RLSE), //DCB=(DSORG=PS,RECFM=FB,LRECL=80,BLKSIZE=3120) //CMSYNIN DD * NDEVDEVD,DISCADM %* DISCIS SYSDB2 CMD MODIFY Thanks for looking, -Norm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
With Appologies to Monty Python
I know the signal to noise ratio is low. I know Darren may not approve. But, I could not resist this little ditty I came up with: OH, I'm a Mainframer, and I'm OK! I work all night, and I sleep all day! I code exits, submit JCL, and run SMP! OH, I'm a Mainframer, and I'm OK! I like to code in COBOL and write project plans! I write memos, status reports, structured code! I wish I were an end user, just like my dear Papa! When in doubt. PANIC!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Blocksize and speed limit on an FICON channel
Bruce, Right know I don't they are leapfrogging at all - the choke is FICON rather than hardware. Both disk and tape can deliver sustained data rates of 160MB/sec because that's all that FICON can do. This is the rate for the latest 35392 if you are getting 3:1 compression, and this is the rate for modern arrays if they are using a reasonable array scheme. If the disk is RAID-1 then of course tape is faster, and if the tape is not compressing well then disk will be faster. My opinion is that RAID using 10K and 15K large form factor disks have been staying well ahead of LTO for a few years now. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black Sent: Thursday, 27 July 2006 4:53 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Blocksize and speed limit on an FICON channel This has not been true for a long time. Pre-fetching concurrently of 4 or 8 drives is much faster than a single tape drive can handle. Ron, I agree, but unless you have a product like ExHPDM to write multiple concurrent backups to a single tape, it doesn't help. Dumping 1 disk to 1 tape, or 10 disks to 10 tapes, there seems to always be a tape drive on the market which is faster than fastest available disk. They keep leapfrogging, of course. -- Bruce Black Senior Software Developer Innovation Data Processing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSAM Checker
You can lookup those codes under msg IDC3009I -- Bruce Black Senior Software Developer Innovation Data Processing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Two New Redbooks on Mainframe SOA
Actually these two are redpieces, so they're more concise. Probably not a bad thing for busy managers. The Role of IBM System z in the Design of a Service Oriented Architecture http://www.redbooks.ibm.com/redpapers/abstracts/redp4190.html The Value of the Mainframe in Service Oriented Architecture http://www.redbooks.ibm.com/redpieces/abstracts/redp4152.html - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries Tokyo (Serving IBM Japan and IBM Asia-Pacific) E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: looking for an example of RDJFCB in 31 bit
In [EMAIL PROTECTED], on 07/26/2006 at 07:45 AM, Charles Mills [EMAIL PROTECTED] said: Isn't ARL a feature of RDJFCB? Yes; it uses a newer exit type instead of the JFCB exit. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Looking for non-English text (UTF-16) for lab data
In [EMAIL PROTECTED], on 07/25/2006 at 11:47 PM, Gerhard Postpischil [EMAIL PROTECTED] said: Close; try Ha ek (and Dvo ak) I'd like to, but my mail reader doesn't seem to support UTF-8. The C48D and C599 display as spaces. :-( -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
At 09:02 -0500 on 07/26/2006, Jeff Horenstein wrote about snding svc dumps: Let us say you have an svc dump that a vendor needs to debug a prolem. Given that svc dumps can contain sensitive data, in particular likely passwords in a dump generated by an ftp server, I was wondering how other sites typically handle this. Are you trying to hide the data, the code, or both? If only the data, just do with you do with new code that you are testing before putting it into production - Use TEST not LIVE Data. Since the TEST data is Phoney (it: Formatted correctly but not sensitive), you are not exposing anything in the dump. If you are worried about passwords, set up a system on your Sandbox Image and use special Passwords that are only valid there. None of the above may be possible in your situation, but if/when it is, this may be your solution. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Associated Press: 540,000 New Yorkers at Risk of Identity Theft
On Jul 26, 2006, at 2:45 PM, McKown, John wrote: --SNIP-- Sounds like the PC in question should have had all sensitive data placed on an encrypted partition / filesystem. I think that Windows allows this. I know that Linux has the ability. I have no idea one way or the other about Mac. Actually, in order to be secure, encrypt the data on the mainframe before shipping it to the laptop. Now refuse to give anybody the key. grin John, There was an item in the news today (IIRC) that MS has essentially stopped shipping (supplying might be a better term) this facility. Ed -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Authorized Command error
There is nothing better then invoking ISRDDN and the, trying to LOAD RECEIVE. It will tell you where it took it with all module library information. Itschak -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Pace Sent: Wednesday, July 26, 2006 6:03 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Authorized Command error Are there other non-authorized libraries concatenated in the STEPLIB with SYS1.LINKLIB? I found it. Doing a DDLIST again and looking for the steplib I found that the IKJACCNT proc had been changed to SYS1.LINKLIB on a VOLSER in the maintenance volumes. I changed that back to the production VOLSER and it worked fine. Thanks for the assistance. Mark D Pace Senior Systems Engineer Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 Office: 850.219.5184 Fax: 888.221.9862 http://www.mainline.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
List of instructions by architecture level?
Is there a concise list somewhere of specific machine instructions available by architecture level? Is architecture level an unambiguous term? I'm looking at the levels as defined in the description of the C/C++ compiler ARCHITECTURE option. Charles Mills +1-707-291-0908 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What's driving my temp data sets to Catalog processing?
We had an issue a couple of years ago where OEMs were using the services (I believe IGWASMS) to determine if a data set is SMS-managed. Thanks for the reply Mark. I don't think that is the case. I've been running the Module Fetch Montitor (Peter Relson's utility) all day and I've only seen one LOAD of IGWASMS, and that seemed to coincide with an SB37 abend. They are not temporary data sets. They are real data sets, with names deliberately chosen to merely *look* like temporary data sets. As permanent data sets, MVS processing deals with them just like any other permanent data set. I cannot remember exactly why at the moment, but that's how CA-Endevor works. Thanks Brian for that reply. I hope that is not the case, otherwise I won't be able to change those *temporary data sets* to use VIO if they are only temporary in name. I now don't understand the SVC 26 request unless it is simply a query, altough the PLIST looked to me as if it was trying a DEFINE. Also, if it was trying to catalog the dataset I would have expected security violations for update attempts to the master catalog which I'm not seeing. Additionally, it is an SMS requirement for permanent datasets that they be catalogued, so I'm not able to put all the pieces of the puzzle together yet. Tom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: snding svc dumps
my organization is effectively a service provider to business fanchises operating in other countries. So for their customers, our site is the third party. We are not permitted to release customer data to anybody. So unless a dump can be visually validated to not contain customer data it will not be released to a vendor. These days my IPCS skills are increasing, as I have to be the hands and eyes (and censor) to the vendor's problem support teams. I am getting very good at running IPCS in batch to generate selected, highly targeted, reports which can be easily verified as containing no customer data. It means that vendors problem support teams really must know what they are doingbecause the ability to browse a dump just doesnt exist. Regards Bruce Hewson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
