Re: SETROPTS ERASE(ALL)
Hi Jack - For many, many years we had been iteratively testing the Erase-On-Scratch function to determine if the performance had improved over time (with new hardware/software releases) to determine if we could exploit EOS, but without getting too far into the weeds, the bottom line was that the overhead to implement EOS was too great--specifically the elapsed time. IBM did great work to dramatically improve the performance over time, but there was always going to be additional CPU and EXCP overhead--no way to avoid that. But we determined that the elapsed time it would take to scratch some of our larger data sets would negatively impact our batch window, so we never implemented it. Yes, you can select certain data sets instead of using "ALL", but that involves too much administrative overhead (and continuous updates as the environment changes) and at the end of the day, some of the largest data sets probably have the most sensitive data in them. That said, you might want to check out IBM APAR OA61492 (and associated PE fixes). The DASD UNMAP function (or the non-IBM DASD equivalent) seems to perform "the same" Erase-On-Scratch function... but at the hardware level. We are using the EMC equivalent and it is working seamlessly--no z/OS side overhead at all and practically nothing at the DASD hardware level. Larre Shiller US Social Security Administration “The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF & TSS (RACF)
Mark - We use Top Secret as well and had the same issue that you are describing when we initially activated JESSPOOL control. We happen to be using (E)JES instead of SDSF, but essentially we did the same thing that Robert described here--we use an (E)JES exit to alter the RACF call for JESSPOOL and set LOG=NOFAIL (as well as MSGSUPP=YES). It does exactly what is necessary to make this function as you wish. Obviously, I cannot comment on why the change that you made to SDSF did not appear to work, but if you can get SDSF to set LOG=NOFAIL for the security calls, Top Secret should "honor" that. If you can't get it to work, perhaps you could open a Case with Broadcom and trace the security call to figure out what's going on. Larre Shiller US Social Security Administration "The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Producing throwaway SMF?
Hi Mike - I know it's not a "Product", but we use a simple SMF exit for this very purpose. Larre Shiller US Social Security Administration “The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help with SCHEDxx Parmlib vs. IEFSDPPT in Linklib
Hi Lizette - We used to meticulously go through the SCHEDxx defaults and carefully "nullify" any entries for products that we were not using, but it just became an administrative and logistical headache. So, after some amount of research and internal discussion, we finally decided that this really wasn't an issue because unless somebody were to install a program into an APF-authorized library (...you do restrict and monitor that, right...?) with the same name as that in the PPT, the entry in the PPT wouldn't be any more of a risk than any other program that could get linked into an APF-authorized library. See the discussion in the section entitled "Auditors: Check the PPT" in: https://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__April_2013.pdf ...at least that was *our* thinking on this. Larre Shiller US Social Security Administration “The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More DISA STIG Audit - stuff
Carmen - You might also find the MVS "D PPT" command of interest, if you are are not already aware of that command. It does display both the PARMLIB and DEFAULT values. We issue that command during each automated IPL as an AUDIT artifact. Larre “The opinions expressed in this post are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: load modules
Dean - ...how about using the TSO ISRDDN command followed by LOAD module_name ...? Larre Shiller US Social Security Administration “The opinions expressed in this post are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF exit IEFU086 work area size
David - Based on some ESP notes that I have from our z/OS 2.3 install, it looks like the work area size is 1024 bytes. The parameter list is mapped by MACLIB(IFAEXITP). I see no evidence to indicate that the length can be set/modified by the installation. Larre US Social Security Administration "The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Erase On Scratch
Starting with z/OS 2.1 and continuing with z/OS 2.2, IBM has improved the performance of the Erase-On-Scratch (EOS) function over the pre-z/OS 2.1 releases by increasing the number of tracks that can be "erased" in each channel program from 1 to 255 to 12,240. The good news is that with those changes (on the software side) there was a drastic reduction in both elapsed time as well as an I/O count reduction, but these I/O operations are asynchronous and as such, most customers are concerned about suffering the performance hit that it takes to implement EOS, especially with replicated DASD. IBM believes that there is a lot of latent interest in using this function, but most customers are simply not using it because of the potential performance impact, including myself. And even if customers are using it, they are using it only for a subset of data sets. IBM would like to drive the use Erase-On-Scratch use up and get most, if not all customers using it because of the security exposure that exists and that IBM would like to eliminate. IBM has been having some internal discussions about improvements that revolve around a combination of hardware/microcode and z/OS software changes that, if implemented in z/OS and the DASD subsystem, would bring the overhead of using EOS down to the point where the overhead would not be noticed. But... the folks involved in bringing that to market need our help. There's an RFE that we can vote for that would show the level of interest in this function. If your Auditors or internal security folks are concerned about residual data on DASD and would like to see you using EOS but you are concerned about the overhead, please consider voting for the following enhancement to help bring this new functionality to market: https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=134047 Thanks! Larre Shiller US Social Security Administration -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS V2R5 Will be the Last Release to Include JES3
> Do you the think the z/OS overall ecosystem and the platform is made stronger > or weaker by getting to one JES? Well... I guess there are a number of ways to look at that. But I think that IBM runs the risk of losing some number of z/OS customers as a result of this, which could in the long term affect the overall IBM revenue stream and the life expectancy of the z/OS platform. I have to assume that the number-crunchers at IBM have already factored this into their calculations and have come to the conclusion that the risk is worth the reward here. In the near term, some larger and more complex JES3 installations, and especially those in the public sector that have constant external pressure put on them to "modernize" their systems (whatever that means... typically meaning "move to Linux" or "the AWS cloud"), may simply take this opportunity to move to a completely different platform. Or simply speed up the already on-going effort to eliminate (what is perceived as) legacy software with a high "technical debt" cost by moving to a different/modern platform. This is indeed a very real risk... and IBM has put many of us in a box. For those JES2 shops out there... imagine how your shop has grown over the past 30 years and what products/services that you support that have an API or in some way interface with JES. Just imagine what would it take for you to be able to know for sure that this conversion will be 100% successful? IBM can add as much JES3 functionality into JES2 as it wants to, but at the end of the day, you still have to do the conversion and ensure that your environment is 100% functional the day after the conversion. And how much fun do you think it will be to convert 16 SYSPLEXes and 300K MIPS-worth of workload (OK, so 30% of it is in a single SYSPLEX)...? A JES3-to-JES2 conversion effort is a high risk change that requires essentially the same level of effort as a conversion from one platform to another--but it has the disadvantage of a 100% "must-go-right" overnight IPL switch. And in the end, there's nothing to show for it... other than a 2 instead of a 3 and a line item in the CxO's spreadsheet that shows the millions of dollars spent on R, additional products, test time, personnel costs and lost productivity. Also, I certainly would not want to be the public official testifying in front of a Congressional panel the week after seeing the "Critical System Failure Affects Millions of Seniors" headline in the local paper. Would you put your professional reputation on the line and tell your CxO that "everything is going to be all right" the day before a conversion like this? On the other hand, moving to a different platform allows a staged application migration and a completely modernized environment--rich with new functionality and without the "legacy" problems that persist on z/OS while at the same time minimizing and compartmentalizing the risk to critical production applications. So... why would a CxO choose to spend millions of dollars on a costly and risky conversion effort (even if it were logistically possible), instead of using those same funds to completely modernize that same environment...? Similarly, very small shops that do not have the personnel or resources to perform a conversion will probably wait this out for a while and then simply move off the platform. For medium-sized shops, it's probably a wash. Overall, the number of customers affected here is probably rather small, but given the size of some JES3 shops, if this chases away enough JES3 shops, it could seriously negatively affect the overall installed MIP count and thus the long term stability of the platform. So... perhaps the shops that remain on z/OS will be in a better position... at least for a while, until those remaining shops also start drifting away from the platform for one reason or another until eventually there's nobody left to turn out the lights. Larre Shiller US Social Security Administration Office: 410.965.2209 “The opinions expressed in this post are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] DISA STIG and permission/audit bits
Yeah... I know. That being said... perhaps the READ ONLY option is something that we can try. Thanks for making that suggestion. Larre There is no way in that I'd be messing with permissions bits on anything IBM provided. We do mount all of that READ only however so that contents cannot be changed. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Larre Shiller Sent: Wednesday, September 26, 2018 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] DISA STIG and permission/audit bits As part of a recent audit, we have been goaded into updating the permission and/or audit bits on certain Unix directories per the DISA STIG (which we use as our risk model). Those directories include many that are shipped by IBM and it's a fair bit of research/work. So... you can easily imagine the problem here--when IBM ships a new release of z/OS or makes changes to either the directory structure or to the existing directories, our changes are backed out. We have been trying to figure out a semi-automated "best practice" that would satisfy the Audit requirement, but have not had much success. So... we started to wonder if anybody else is doing this and if so, how do they manage to keep track of directory changes and keep them updated per the STIG. Any advice would be gratefully appreciated... Thanks. Larre Shiller US Social Security Administration “The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DISA STIG and permission/audit bits
As part of a recent audit, we have been goaded into updating the permission and/or audit bits on certain Unix directories per the DISA STIG (which we use as our risk model). Those directories include many that are shipped by IBM and it's a fair bit of research/work. So... you can easily imagine the problem here--when IBM ships a new release of z/OS or makes changes to either the directory structure or to the existing directories, our changes are backed out. We have been trying to figure out a semi-automated "best practice" that would satisfy the Audit requirement, but have not had much success. So... we started to wonder if anybody else is doing this and if so, how do they manage to keep track of directory changes and keep them updated per the STIG. Any advice would be gratefully appreciated... Thanks. Larre Shiller US Social Security Administration “The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MSG IEFA111I SWA=BELOW,TIOT SIZE=32K,DSENQSHR=DISALLOW,GDGBIAS=JOB
Ding! I asked IBM about this message earlier this year and here was the response: "After examining this issue, we do agree the documentation in the V2R3 z/OS MVS System Messages, Vol 8 (IEF-IGD) for Message IEFA111I is incomplete. We spoke with development and they already created a RCF, Reader's Comment Form, for this issue. The documentation will be updated in the next book release. In regard to SWA, all started tasks/jobs submitted under JES3, will default to JES3's settings. However, if a started task were to run under SUB=MSTR, then the IEFA111I Message will always output SWA=BELOW. Currently, all started tasks submitted under MSTR will be ran with SWA=BELOW. Please Note: Any task(s) started before JES will also run under MSTR as well." Larre -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The IRS Really Needs Some New Computers
On Tue, 17 Apr 2018 19:19:07 -0700, Ed Jaffe <edja...@phoenixsoftware.com> wrote: >On 4/17/2018 3:55 PM, Edward Gould wrote: >> >> I can’t speak to the IRS but the Social Security system (last I heard) was >> *WAY* out of date by at least 20 years (maybe more). Can anyone verify (or >> not), please? > >SSA runs one of the most sophisticated data centers of any government >agency I've seen. > >They own all the latest kit and participate in nearly every z/OS ESP. I >know this for FACT! > Gee, thanks Ed...! It's certainly not easy managing 150,000MIPS of WebShpere on Z, let alone the 150,000 GP MIPS of "everything else". And speaking of IT modernization efforts, I thought that this was rather timely and informative: https://federalnewsradio.com/it-modernization-month-2018/2018/04/social-security-on-schedule-to-modernize-it-systems-by/ ...it's a 20 minute listen, but it gives you a good idea as to where we are and where we are headed in the future. I guess you could get into a discussion about what we are running that is "out of date", but certainly our IT infrastructure is *not*. Are 40 year old COBOL programs "out of date"...? Well... they may have some "technical debt" associated with them and sometimes maintaining them can be challenging, but does it really matter if I'm running a COBOL or a JAVA program to add up a column of numbers? Larre Shiller US Social Security Administration “The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBMLINK SIS Failing? Spurious Error 500's
Yes, indeed... I am forced to use IE and like you, I have been suffering with this for quite a while, but it has gotten much worse this past week. In fact, at this point, it's almost unusable... almost every time I attempt to navigate around ServiceLink (usually starts with a "back" request), I get the error and I have to re-authenticate to "fix" it... but even after that, it has gotten to the point where I can't even navigate away from the main menu. Larre Shiller US Social Security Administration “The opinions expressed in this post are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT
Hi Lizette - I would say that we are a fairly large DB2 shop and we are using both of those functions... that is, USEZOSV1R9RULES(NO) and MEMDSENQMGMT(ENABLE) and we have been using them since they were first available. I think we may have opened a PMR for a problem that we initially had with MEMDSENQMGMT, but since then, we have not had any issues related to these 2 functions. You asked about other parameters... we are also using VSM BESTFITCSA(YES). Again... as far as I know, we have had no issues with it. In all cases, I'm not sure that I have any way to quantify the potential performance or functional improvements associated with these parameters. And I cannot remember any specific software products that needed to be updated as a result of activating these functions--but again, that was a long time ago... I'm sure at this point, any changes required would have already been implemented. Larre Shiller US Social Security Administration “The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM to stabilize JES3 (was: IBM to finally drop JES3)
...in fact, the Statement Of Direction doesn't even mention the word "stabilization"...! For the record, it states: For several decades, z/OS has offered two spooling subsystems: JES2 (formerly HASP) and JES3 (formerly ASP). JES2 is used by the majority of z/OS customers and has evolved into nearly a superset of functionality over JES3. IBM is affirming that JES2 is the strategic Job Entry Subsystem for z/OS. New function in spooling subsystems will be primarily developed only for JES2. JES2 supports unique features in the area of availability such as spool migration, online merging of spool volumes, and in the area of function such as support for email notification when a job completes and soon in the area of security with encryption of spool data. JES3 continues to be supported and maintained with its current function. So... the only thing that it actually says about the future direction of JES3 is that "...JES2 is the strategic Job Entry Subsystem for z/OS" and that "...new function in spooling subsystems will be *primarily* [emphasis mine] developed only for JES2." To my mind, that doesn't mean that no new functionality will be introduced to JES3... only that the focus will be on adding functionality to JES2. Now I suppose that one might equate all of that with "stabilization"... but truly, that's not one of the carefully chosen words the SOD and it's a characterization and a direction that SSA (as a JES3 customer) will certainly be pushing back on. Larre Shiller US Social Security Administration "The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMFLIMxx sample?
Hi Curtis - We use SMFLIMxx... here's a sample of the REGION statement: REGION SUBSYS(JES3) REGIONABOVE(NOLIMIT) REGIONBELOW(NOLIMIT) EXECUTE(YES) ...it's fairly free-form. Note that a complete description and syntax can be found in APAR OA47062 and here: http://publibz.boulder.ibm.com/zoslib/pdf/OA47062.pdf You'll also want to take note of APAR OA49546 for a DOC correction as well as defect related APARs OA52045 and OA52624. Larre Shiller US Social Security Administration "The opinions expressed in this post are mine personally and do not represent the opinion of the US Social Security Administration and/or the US Government." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Survey: How many APF-authorized libraries?
...depends on the SYSPLEX, but our largest production PLEX has 352 at the moment. Larre Shiller US Social Security Administration “The opinions expressed in this e-mail are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government.” -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Erase on Scratch
Ed - Yes. Larre -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Erase on Scratch
I have been involved in a number of offline discussions as well as multiple IBM PMRs and problem records with our DASD hardware vendor concerning EOS and although this is potentially a most useful function, the overhead involved is not zero--there will always be *some* amount of overhead involved in re-writing every bit of a data set, no matter how much improvement IBM has made to the function at the OS level (such as the 95+% reduction in EXCP's since the initial implementation of EOS). During our testing, we find that it takes an additional 1 hour of processing time for every 500G of data in order to use EOS. If you have a tight batch window or any kind of time-sensitive processing, you should make sure that you can afford to use EOS before simply activating it for every data set in your enterprise. Since this is a security-related function, I will not comment publicly if/when/where we do or do not use it, but I will simply recommend that you perform a benchmark evaluation of the overhead involved on your hardware before activating EOS. Larre Shiller US Social Security Administration "The opinions expressed in this message are mine personally and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Automatic Binary Optimizer (ABO)
...are you confusing complementary with complimentary...? Larre -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dynamic allocation for tape using TSO in batch
Well... after much testing and back-and-forth with IBM, the bottom line is that you *can* control the ability to dynamically allocate a tape data set from a program running under TSO in batch. As a few folks mentioned, this is controlled by the addition of a TSO segment to the batch User ID and the MOUNT authority, as long as the batch User ID is 7 bytes or less (otherwise the job gets the TSO default of NOMOUNT). I do not know why this did not work the first time we tried it, but it works now. Thanks to everyone for all of the suggestions! Larre Shiller US Social Security Administration -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
dynamic allocation for tape using TSO in batch
Hello - Please excuse the lack of detail in this post... I'm not a COBOL programmer and quite a bit of what is happening here is either outside of my scope of understanding and experience or I have no way to directly test some of this. There are quite a few moving parts involved and I'm not sure which one may be the culprit. We have a production batch job that executes DB2 and a COBOL program using TSO in batch (IKJEFT1A). The COBOL program dynamically allocates DASD data sets as input using PUTENV and standard COBOL SELECT and OPEN statements. The COBOL program uses the CATALOG to get the data set names it is interested in uses the DSN to do the OPEN. This has been working for years. Unfortunately, some of the input data sets chaned from DASD data sets to TAPE data sets and the job is now getting failure to allocate messages: IKJ56221I DATA SET FOO.BAR NOT ALLOCATED, VOLUME NOT AVAILABLE+ IKJ56221I VOLUME NECESSARY TO SATISFY YOUR REQUEST NOT ON SYSTEM, AND CANNOT BE MOUNTED ...and since we are a JES3 shop, this one gets thrown in as well: IEF295I FOO.BAR - VOLUME MOUNTING NOT ALLOWED BUT IS NEEDED BY JES3 INITIALIZATION I find the IEF295I message (and descriptive text) to be especially cryptic and confusing. I'm not quite sure what failure to mount a volume has to do with JES3 INITIALIZATION, but I suspect the message is probably just ancient and poorly worded... I opened a PMR with IBM, but the essence of what I'm getting back just boils down to ...you can't mount a tape from a batch job executing TSO And although that certainly seems to be the case here, I guess I'm just skeptical. And I can't seem to find that blanket restriction specifically documented anywhere. I have found numerous other can I dynamically allocate a data set from a COBOL program posts on the Interwebs and I have read quite a few of them, but none of them specifically mention tape--at least not the ones that I can find. And one would think that if that were a restriction, it would have been discussed or mentioned in at least *one* of them...! But maybe not. We even tried adding a TSO segment to the batch userID and gave it MOUNT authority, but that did not help. It seems awfully odd that there is no way to permit this, if this is indeed a default behavior/restriction... after all, even with the TSO restriction, you can still override it with UADS or TSOAUTH...! I guess I'm just looking for definitive confirmation one way or the other and was hoping that somebody would have specific knowledge or experience here. Thanks for any help... Larre Shiller US Social Security Administration -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dynamic allocation for tape using TSO in batch
Hi Lizette - Thanks for the suggestions. I do have a SLIP dump that IBM is working from... but I guess I need to get them focused on the failure a bit more. Otherwise, I checked all of the usual suspects and there is no environmental issue that is preventing the tape mount. This appears to be an issue with some bits in the PSCB--at least from the preliminary information that I have. The APAR you mentioned does not appear to be applicable--we do have that installed. Larre You need to find out why the tape did not mount. You can use RMF to get the enqueues to see what might have been going on at the time of the allocation. You can check syslog when the batch job ran and see if there are any message for the dataset or volser. You can check to see if you have enough tape drives when the job ran to mount the tape. See if this apar is applicable. PM76846: IKJ56221I VOLUME IS ALLOCATED TO ANOTHER JOB OR USER, TRY LATER INZI330E DYNAMIC ALLOCATION FAILED Check to see if all maint is installed for DB2 and z/OS for this error message. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multiple TSO Sessions
Mark - We have this working in our JES3 environment at z/OS 2.1. No USERMOD required. Larre US Social Security Administration The opinions expressed in this e-mail are mine persoanlly and do not necessarily reflect the opinion of the US Social Security Administration and/or the US Government. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
