Re: Jcl
Hi, With regard to the query: I have a requirement in which based on the day we need to execute the step ie for eg if it is monday then we need to execute the sep2 or else or other days we need to skip this step and execute the other step/ Please any one how this can be coded in the jcl Whilst Itschak's response is valid, I would urge the use of a scheduling package such as OPC (TWS), Control-M, or CA-7 especially if this is a regular requirement. These products were designed to address this specific requirement whereas JCL is NOT. Kind regards - Terry Terry Sambrooks Director KMS-IT Limited 228 Abbeydale Road South Dore Sheffield S17 3LA UK Tel: +44 (0)114 262 0933 WEB: www.legac-e.co.uk Reg: England Wales 3767263 at the above address All outgoing E-mails are scanned but it remains the recipients responsibility to ensure that their system is protected from viruses, trojans, worms, and spy-ware. -- 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: Non-SMP/e packaging
I'm not CA-1 customer. Personally I would choose SMP/E, however it could depend on how the alternative way is designed. From the other hand I understand people who don't want SMP/E. It is too complex, and its complexity could give more troubles than profits. It is possible to do it simpler. It's funny when someone ask about SRELs, the names 30+ years old - obviously missed conception. It is horrible how many commands, structures, objects are inside of SMP/E. It's both funny and horrible when I get CBPDO order: 40 tapes, only 5 of them contains product code, 7 are empty (!) and 28 contains single text file - in fact some kind of installation description (and PTFs to be honest). From the other hand g SMP/E already exist, while non-SMP/E method would be either very limited or would have to be created. -- Radoslaw Skorupka Lodz, Poland Russell Witt wrote: I had a request from a client today, asking when CA-1 would stop being delivered in SMP/e format and would be a simple library-download. From my other talks with clients, I thought everyone wanted products delivered in SMP/e format. And this was the first time I had seen a request to go backwards to simply giving people a loadlib that they could refresh on a monthly/quarterly basis as required. This client pointed to a number of other products that do not use SMP/e and he felt SMP/e way to cumbersome to deal with (obviously, he was in charge of OEM products and not maintenance to the operating system itself). Still, I have to ask, would clients prefer to have an optional non-SMP/e installation procedure even when it means having to download a fresh copy of the product in order to apply maintenance? I am not saying I can change the packaging of CA-1 by myself, but if many clients are interested it is something I can push for. I have just never seen a request like this before. Russell Witt CA-1 Level-2 Support Manager -- 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
Help Needed when LINKing to IMS Program cross CICS Region
Hi, Could anybody help me (or continue the request to CICS or IMS expert) We are having a condition, and maybe anybody had this experience/know the solution. I have a CICS-IMS Program running in one CICS Region needed to be LINKed by another CICS Program (cannot access IMS database because it sits in different SYSPLEX) is having ADPL ABEND (unsupported DPL command) After we look-up in IBM documentation, we found EXEC DLI TERM is not supported when the program is LINKed from another CICS Region. How to resolve this? The problem we cannot take out this command, because the LINKing program is going to to repetitive LINK towards this CICS-IMS Program before terminate and we will get another ABEND DHTC (trying to SCHEDULE a PSB without terminating the previous one). Is there any equivalent command which complies to DPL standard? Or an Implicit PSB Termination Technics? Any command would be appreciated. Thank you Best Regards, Fransiscus Kaurrany -- 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: Is it possible to prevent a structure into a particular CF (C oupling Facility)?
snip Re. Paolo Cacciari saying: Obviously, I assume that your Data Centers are not involved in a Dispersed Parallel Sysplex. It *IS* about a GDPS config, Paolo, with the K-sys controlling system in the C/R site. snip What kind of D/R you want to have? What do you plan for the case that you have disk problems only? You move all your systems to the site-2 after recovering the secondary volumes or you want to be able to use the secondary volumes running the systems in the site-1? The way I understand Paolo's question is: you don't plan to disperse the application systems over both sites, some of htem running in the site-1, the others in the site-2? Zaromil -- 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
IEC070I 211(8,17107)-221
Dear All, we got some problem about file extension ,but I'm not clear about the following message : ICH408I USER(CUPFNF1 ) GROUP(CICS) NAME(CICS REGION PROD) 298 PVOFNF.RM.RM.P140.RMHSTM.V CL(DATASET ) VOL(JAPSYS) INSUFFICIENT ACCESS AUTHORITY FROM PVOFNF.** (G) ACCESS INTENT(ALTER ) ACCESS ALLOWED(CONTROL) IEC070I 211(8,17107)-221,CPSPFOR1,CPSPFOR1,RMHST01,5325,APOLXD, IEC070I PVOFNF.RM.RM.P140.RMHSTM.V,PVOFNF.RM.RM.P140.RMHSTM.V.DATA, IEC070I CATALOG.FNFALLP According to IEC070I,this file tried to extend to APOLXD,but it cannot due to authority. we have the other files (access allowed=control for CUPFNF1) that can extend without the problem . What happen to this file? Any suggestion/explanation will be appreciated. Regards, Sathaporn DISCLAIMER: This e-mail is intended solely for the recipient(s) name above. If you are not the intended recipient, any type of your use is prohibited. Any information, comment or statement contained in this e-mail, including any attachments (if any) are those of the author and are not necessarily endorsed by the Bank. The Bank shall, therefore, not be liable or responsible for any of such contents, including damages resulting from any virus transmitted by this e-mail. -- 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
IEC070I 211(8,17107)-221
Hi, In respect of: ICH408I USER(CUPFNF1 ) GROUP(CICS) NAME(CICS REGION PROD) 298 PVOFNF.RM.RM.P140.RMHSTM.V CL(DATASET ) VOL(JAPSYS) INSUFFICIENT ACCESS AUTHORITY FROM PVOFNF.** (G) ACCESS INTENT(ALTER ) ACCESS ALLOWED(CONTROL) IEC070I 211(8,17107)-221,CPSPFOR1,CPSPFOR1,RMHST01,5325,APOLXD, It seems to me that the issue is NOT IEC070I but the preceding ICH408I which states that User CUPFNF1 has CONTROL authority over the data set in question but is trying to functions which require ALTER access. The Security (RACF) administrator needs to be involved here I believe to ensure that correct access is grantted via the generic profile PVOFNF.** Kind regards - Terry Terry Sambrooks Director KMS-IT Limited 228 Abbeydale Road South Dore Sheffield S17 3LA UK Tel: +44 (0)114 262 0933 WEB: www.legac-e.co.uk Reg: England Wales 3767263 at the above address All outgoing E-mails are scanned but it remains the recipients responsibility to ensure that their system is protected from viruses, trojans, worms, and spy-ware. -- 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: Are posts from Annie and Leon Wheeler a bot or something?
tony babonas [EMAIL PROTECTED] wrote: Whatever their site is I'm deeply envious of how comprehensive its contents are. The design must be such that: 1. It's readily update-able. 2. It's readily search-able, in that a reference to the 1978 version of the ABC Frammis get quoted rather instantly. 3. Seeming non-redundant, though I must admit I only read a few additional peripheral links. Lynn Wheeler was one of the very early VM developers. He's been around IBM for 30+ years, starting as a student. That doesn't answer the questions about the site, but that's WHO he is, anyway -- he's got the chops, he knows what he's on about. ...phsiii -- 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
OA17218 closed with PTFs. We appreciated the original heads up as we have been in the process of replacing some older storage processors with new technology so we made the workaround known to the folks responsible for handling the IODF changes. Thanks, Sam APAR Identifier .. OA17218 Last Changed 06/09/06 RANDOM OVERLAYS DUE TO INCORRECTLY BUILT SSCB TABLE 06/07/12 PTF PECHANGE Symptom .. IN INCORROUT Status ... CLOSED PER Severity ... 1 Date Closed . 06/08/21 Component .. 5695DF111 Duplicate of Reported Release . 1J0 Fixed Release 999 Component Name DEVICE SUPPORT Special NoticePE HIPER Current Target Date ..06/09/01 Flags RESTART/BOOT/IPL SCP ... Platform Status Detail: SHIPMENT - Packaged solution is available for shipment. PE PTF List:UA18400 UA18402 UA18401 UA20831 UA20830 UA20832 UA20833 PTF List: Release 1G0 : UA28564 available 06/08/30 (F608 ) Release 1H0 : UA28565 available 06/08/30 (F608 ) Release 1J0 : UA28584 available 06/08/30 (F608 ) Release 1K0 : UA28585 available 06/08/30 (F608 ) Parent APAR: Child APAR list: ERROR DESCRIPTION: An an OUCB was found to be overlayed by an SSCBDH overrunning its length, causing an abend0c4 pic10 IRASAMSU/UA15188+998. The SSCB table is built incorrectly overlaying MVS control blocks. . The sequence that causes this failure: 1) An IPL or initial Vary Online of DASD device in SSID. Ex. 10 devices for this example 2) Configuration change to delete some devices with this SSID Ex. 5 deleted for this example 3) Configuration change to add devices with same SSID Ex. 3 added for this example --- Problem: New Table built and size getmained is for 8 devices. However device counter still set to 10. 4) Now, 2 more devices are re-configured / added back to this SSID. Device counter is off so we think we have room for 2 more devices in the table. Getmained area was only for 8so we overlay storage following. . Additional abends observed, though there may be others: IAXVP/HBB7709+A00 abend0c4 pic4 IAXIR/HBB7709+766 abend6c5 rsn1c023120 IRARMINT/HBB7709+69E abend15f rsn18 IRAQUEUE/UA16164+141A abend15F rsn0152 IAXIS/UA13982+1c9e abend0c4 pic10 . LOCAL FIX: Avoid reconfiguration for an SSID that currently has any devices already online to that host. . Bypass process below is discussed in TECHDOC ITEM S1002495 . There are only 2 bypasses for deleting and re-defining the SSSCB Device Table: A) IPL -OR- B) Follow the procedure below (from S1002495) to manually delete and re-define. At least one volume will have to be varied offline while this procedure is done. . Delete / Redefine Procedure 1) Make sure one device is taken offline. Yes it can be a dummy device, or it can be any other device in the SSID. - Pick the device in the SSID you can most afford to have offline. 2) Issue the DELETE command: DS QD,SSID=,DELETE This will delete the current device table. **IMPACT - limited to a small timing window for products that use that table. This would include SDM (like flashcopy), SMS, and RMF. The last two are strictly related to statistics gathering. 3) Vary the offline device, or devices, online. 4) Then issue the VALIDATE for each string of devices. For example, if a given device string began at a000 and there were a total of 256 devices, then you would issue: DEVSER QD,A000,256,VALIDATE . The offline devices will be added back in to the table by the VARY ONLINE in #3. The existing online devices will be added back in by the VALIDATEs you do for every device/string of devices (#4). PROBLEM SUMMARY: * USERS AFFECTED: DFSMS USERS DYNAMICALLY ADDING D/T2105 * * D/T2107 D/T1750 D/T3990 WITH 2 CONTROL * * UNITS HAVING THE SAME SSID * * PROBLEM DESCRIPTION: RAMDOM OVERLAYS OCCURS IN THE SYSTEM* * AFTER DYNAMICALLY ADDING NEW DASD * * CONTROL UNITS. THE OVERLAYS CAN CAUSE * * ABEND0C4 IN VARIOUS COMPONENTS. THIS * * WILL ONLY OCCUR IF THE CONTROL UNITS* * HAVE DUPLICATE SSIDSWHEN ATTEMPTING TO * * VARY ONLINE THE NEW DEVICES.*
FW: Non-SMP/e packaging
While SMP/E may be somewhat cumbersome to use, it is the best repository for keeping information on what exactly is the current maintenance level of a software product. Unloaded libraries may be easier to use but aren't any help when there is a problem and you need to know what level the code is at. I realize that the trend is to 'dumb down' the systems programming requirements, but there are reasons why z/OS is as stable as it is, and SMP/E plays a big part. Personally, I wouldn't want to have to try to maintain and do problem resolution on a system that didn't use SMP/E. It makes my job a lot easier and is well worth the initial extra effort to install a product. Ciao, Jon Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Russell Witt Sent: Tuesday, September 12, 2006 12:13 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Non-SMP/e packaging I had a request from a client today, asking when CA-1 would stop being delivered in SMP/e format and would be a simple library-download. From my other talks with clients, I thought everyone wanted products delivered in SMP/e format. And this was the first time I had seen a request to go backwards to simply giving people a loadlib that they could refresh on a monthly/quarterly basis as required. This client pointed to a number of other products that do not use SMP/e and he felt SMP/e way to cumbersome to deal with (obviously, he was in charge of OEM products and not maintenance to the operating system itself). Still, I have to ask, would clients prefer to have an optional non-SMP/e installation procedure even when it means having to download a fresh copy of the product in order to apply maintenance? I am not saying I can change the packaging of CA-1 by myself, but if many clients are interested it is something I can push for. I have just never seen a request like this before. Russell Witt CA-1 Level-2 Support Manager -- 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: Are posts from Annie and Leon Wheeler a bot or something?
Lynn Wheeler was one of the very early VM developers. He's been around IBM for 30+ years, starting as a student. But, his posts are repetitive, difficult to read, and content-free. I find, as I have said before, no value add. History is one thing. Droning posts are another. 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: HFS Vs ZFs
Functionally stabilized usually leads to dismissal. So, I ass/u/me/d it was. I actually don't remember anyone saying it was going away. Seems that at some point it would be wise to make the move. At 11:03 PM 9/11/2006, you wrote: Brian France wrote: Okay, I know (hope) I'll see this in the manual, but would like to ask ahead of time. IF HFS is indeed going away and zFS is the way to go, does that mean there is a shared zFS ala HFS? Who said HFS was going away? -- 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 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: Orphaned CSA/SQA Storage
APAR Identifier .. PK24960 Last Changed 06/09/12 VSMDATA SAYS STORAGE IS OWNER GONE (OG) Symptom .. IN INCORROUT Status ... CLOSED PER Severity ... 4 Date Closed . 06/07/17 Component .. 5655L8200 Duplicate of Reported Release . 000 Fixed Release 999 Component Name WEBS MQ FOR ZOS Special Notice Current Target Date ..06/10/04 Flags SCP ... Platform Status Detail: SHIPMENT - Packaged solution is available for shipment. PE PTF List: PTF List: Release 000 : UK16225 available 06/09/12 (1000 ) Parent APAR:PK11489 Child APAR list: ERROR DESCRIPTION: VEBRX VSMDATA 'OWNCOMM DETAIL' lists some storage as owner gone, but the storage should be listed as active LOCAL FIX: PROBLEM SUMMARY: * USERS AFFECTED: All users of Websphere MQ for z/OS Version 6 * * using common storage tracking. * * PROBLEM DESCRIPTION: IPCS VERBX 'OWNCOMM' report flags MQ* * storage that is still in use as 'OG'* * (Owner Gone) when MQ pool storage * * extensions were required by a connected * * address space which has now ended. * * RECOMMENDATION: * The storage management routines in the MQ QMGR do not specify OWNER= on their GETMAIN macros - so the 'owner' defaults to the address space in control at the time. MQ storage pools can be extended by the MSTR address space or any connected address space and remain in use by MQ even after the requestor has terminated. This gives a false view of the storage in the CSA tracker data - since the 'OG' storage is in fact reallocated and is in use by other users of the MQ subsystem PROBLEM CONCLUSION: Modules CSQSFBK CSQSFPL CSQSGMN CSQSVBK CSQSVPL CSQYAGCS have been changed to specify OWNER=SECONDARY on their GETMAIN macros for global storage. Code has been added to ensure that the MQ MSTR address space is SECONDARY when the ?CSQSGBLK macros (for obtaining cpool storage) are executed in the following modules. CSQWARDS, CSQWVSMT, CSQWVZCK, CSQWVZSA, CSQWVZSS, CSQ3AM00, CSQ3EXT0 and CSQ3GCAB 000Y CSQSFBK CSQSFPL CSQSGMN CSQSVBK CSQSVPL CSQWARDS CSQWVSMT CSQWVZCK CSQWVZSA CSQWVZSS CSQYAGCS CSQ3AM00 CSQ3EXT0 CSQ3GCAB TEMPORARY FIX: COMMENTS: MODULES/MACROS: CSQSFBK CSQSFPL CSQSGMN CSQSVBK CSQSVPL CSQWARDS CSQWVSMT CSQWVZCK CSQWVZSA CSQWVZSS CSQYAGCS CSQ3AM00 CSQ3EXT0 CSQ3GCAB SRLS: NONE RTN CODES: CIRCUMVENTION: MESSAGE TO SUBMITTER: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Schiradin,Roland HG-Dir itb-db/dc Sent: Sunday, June 25, 2006 7:11 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Orphaned CSA/SQA Storage Well IBM Hursley done a good job to elimiate such orphaned CSA/SQA storage PK11489 for 5.3 (I run a usermod for several months without any problem) PK24690 fot 6.0 (still open) DB2 development close PK10031 as SUG. Requiere BCP support Roland Schiradin 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
Re: JCL
our site has written a program that sets a return code based on the day of the week. subsequent steps use either COND= coding (why?) or IF coding to then selectively run or bypass . Chris Hoelscher IDMS DB2 Database Administrator Humana Inc 502-476-2538 [EMAIL PROTECTED] Hello I have a requirement in which based on the day we need to execute the step ie for eg if it is monday then we need to execute the sep2 or else or other days we need to skip this step and execute the other step/ Please any one how this can be coded in the jcl http://bama.ua.edu/archives/ibm-main.html The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- 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: Non-SMP/e packaging
But some vendors SMP/E usage is even worse than a non-SMP/E install. CA-1 may not be an offender, but I've spent a lot of time fooling SMP/E into applying vendor service that was poorly structured. If there is no trust in the SMP/E environment, it's not worth a 10 fold increase in time of installation. CA used to promote CA-Activator (CA-Aggravator...) installs, may it rest in pieces. While SMP/E may be somewhat cumbersome to use, it is the best repository for keeping information on what exactly is the current maintenance level of a software product. Unloaded libraries may be easier to use but aren't any help when there is a problem and you need to know what level the code is at. I realize that the trend is to 'dumb down' the systems programming requirements, but there are reasons why z/OS is as stable as it is, and SMP/E plays a big part. -- 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: Non-SMP/e packaging
Follow up to my last note; read the CA Common Services install process and see if SMP/E makes it easier. -- 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: Non-SMP/e packaging
Whether one uses SMP/e or a vendor equivalent, it produces a more sound system. I've had products that are load and go (Plug and play?) and while they may work OK, maintenance is usually a module level replace and you aren't really sure what you've got. I've used Activator with similar success to SMP/e, and I've even got my own way of updating exits whereas they aren't usermods. I'm wondering if the originator of the thread is leery of SMP/e, or feels that there aren't enough hours to do it. Daniel McLaughlin ZOS Systems Programmer Crawford Company PH: 770 621 3256 * Rugen, Len [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 09/12/2006 08:40 AM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Non-SMP/e packaging Follow up to my last note; read the CA Common Services install process and see if SMP/E makes it easier. -- 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: Jcl
Hmm. I don't mind the first step sets a cond code idea but there may be many opportunities for uncertainty to intrude unless you pass a PARM= value to that step which explicitly indicates what day this jobstream belongs to. Rhetorical questions for the original poster to ponder : Will the job always be submitted on the same day it's supposed to run? Will it run on the machine it's submitted on? However submitted, how confident are you that the job will *always* start within the day it belongs to? What about situations where production is delayed into the next day? Or run at a DR site? Or run at a DR site in another time-zone? Or re-run in the next day? Or what happens when you want to run several day's production in the one 24 hour period? How important is it if the wrong decision gets made some of the times this job runs? And, more esoterically, what are the boundaries of your production day? Is it a 24 hour day that starts at ? Or at 0800? Or something else? You may already have a naming scheme for one or more of the datasets that the job handles that reflects which day of the cycle is being processed. If that's the case then your initial step might be written to determine the day-of-cycle from a dataset name that is going to be used in the job. ie. you effectively pass a dataset name (via a DD statement in the first step's JCL) to your specially-written step one program. ..and for those who fancy a walk in the wild.. Please do beware the irate bear, with his fearsome claw 'n powerful jaw, 'cos his coughing bark in the moonlit dark, means you've had it! Run!! Regards to all, Graeme. At 03:54 PM 12/09/2006, you wrote: Write your self a program (rexx, clist, asm etc.) that will run as -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Brain I have a requirement in which based on the day we need to execute the step ie for eg if it is monday then we need to execute the sep2 or else or other -- 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
Dr Who destroys Satan with a little help from IBM
Old IBM hardware never dies it seems... http://thenewmainframe.blogspot.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
Jcl
Over the years I've seen a few instances where the scheduling package was the only thing that brought the IPL operator up sharp for an incorrectly input date. If you're going to depend on the system date for correct processing, you should have some reasonableness check in there. I remember using a ver simple one off a GUIDE tape many, many years ago. I used an AD/CD just over a year ago and that did something similar too. -- Phil Payne http://www.isham-research.co.uk +44 7833 654 800 -- 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: Jcl
We had a situation similar to the originator here. There was a job that needed to be manipulated based on the month. I wrote an EXEC which created a JCL that is stored in a PDS. A demand scheduled job kicks it off. Step 1 runs the EXEC, step 2 submits the job to the internal reader. I am willing to send those along. Daniel McLaughlin ZOS Systems Programmer Crawford Company PH: 770 621 3256 * -- 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: Help Needed when LINKing to IMS Program cross CICS Region
Have you tried asking on the CICS List. Go to - http://listserv.uga.edu/archives/cics-l.html and sign up an post the question there. Jim McAlpine On 9/12/06, FRANSISCUS KAURRANY [EMAIL PROTECTED] wrote: Hi, Could anybody help me (or continue the request to CICS or IMS expert) We are having a condition, and maybe anybody had this experience/know the solution. I have a CICS-IMS Program running in one CICS Region needed to be LINKed by another CICS Program (cannot access IMS database because it sits in different SYSPLEX) is having ADPL ABEND (unsupported DPL command) After we look-up in IBM documentation, we found EXEC DLI TERM is not supported when the program is LINKed from another CICS Region. How to resolve this? The problem we cannot take out this command, because the LINKing program is going to to repetitive LINK towards this CICS-IMS Program before terminate and we will get another ABEND DHTC (trying to SCHEDULE a PSB without terminating the previous one). Is there any equivalent command which complies to DPL standard? Or an Implicit PSB Termination Technics? Any command would be appreciated. Thank you Best Regards, Fransiscus Kaurrany -- 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: Non-SMP/e packaging
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Russell Witt Sent: Monday, September 11, 2006 11:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Non-SMP/e packaging I had a request from a client today, asking when CA-1 would stop being delivered in SMP/e format and would be a simple library-download. From my other talks with clients, I thought everyone wanted products delivered in SMP/e format. And this was the first time I had seen a request to go backwards to simply giving people a loadlib that they could refresh on a monthly/quarterly basis as required. This client pointed to a number of other products that do not use SMP/e and he felt SMP/e way to cumbersome to deal with (obviously, he was in charge of OEM products and not maintenance to the operating system itself). Still, I have to ask, would clients prefer to have an optional non-SMP/e installation procedure even when it means having to download a fresh copy of the product in order to apply maintenance? snip Perhaps what you should do is have a survey done of your client base and ask them. But going back a few weeks, there was a discussion about this very thing. Boole Babbage used to provide (for AutoOPERATOR at least) two tapes. The first was the load and go. The remainder and onto the second tape was all the SMP/E files related to that load and go install. It was entirely the customer's choice to only lay down the executables and never put down the backing SMP/E files (basically, the SMP/E install was a copy of the install that was done at ole Drool Babble that had been backed up to tape - everything was there). Customers could choose to re-order the system, and they would get it again, with all the maint already on it (all you had to do was wait until a PUT was produced and then order it - what you got was the customer install system with the PUT already applied). As I recall (this was up to 1993), we had customers who never installed the SMP/E components but only laid down the target files. One might wonder why they would do it that way when some HIPER maint might come out that they absolutely had to have (and yes, that happened a few times too). But, if the customers want things simple, and don't want to take up the space, and you allow them to let you do all their maint and then ship it to them to just lay down... Well, you might be able to market this and have a charge for it. Later, 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: JCL [Conditionals]
In a recent note, Chris Hoelscher said: Date: Tue, 12 Sep 2006 08:01:42 -0400 subsequent steps use either COND= coding (why?) ... Fewer keystrokes? If multiple consecutive steps are to be conditional, I'd certainly use IF. If I wish to disable a single step, it's easier to add ,COND=(0,LE) BTW, it would be a significant aid to programmers to detect nesting errors if the JCL parser enforced agreement of the labels on the IF and the ENDIF. Has anyone wondered why the parser doesn't provide this support? Is there another semantic of those labels which would interfere? -- 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: Non-SMP/e packaging
I would hope 99% of us who have worked on this platform know and understand the benifits of SMP/E. I personally would choose an SMP/E install if I can over a non-SMP/E install but that may just be my old-timer prejudice showing. Trying to keep an open mind... Excluding major components (OS, subsystems like CICS/DB2/IMS etc.), would it really be that bad if you just replaced the run time libs when you needed to upgrade / put on maintenance? Since almost all shops have high speed internet access and vendors have electronic downloads, think of all the time and DASD (even though DASD is cheap) you would save by not having to deal with an SMP/E environment and distribution libs. I hate to say it - but think win-doze, PFCSKs, zNextGen. Think of a small shop with few support people. If we truly want to attract new comers to this platform (or at least keep the existing install base) and make it easier and quicker to install and maintain software, this may be a fine alternative to SMP/E for many products. I think what is important is to know exactly what level of software you are running to help in problem determination and to know where do I go from here to upgrade. If vendors distributed well defined levels of their software in run-time only format, this isn't an issue. A perfect example is Innovation's FDR. I have used it in virtually every shops I've been at for 20+ years. I have never missed having an SMP/E install nor have I had any issues / problems related to problem determination because I didn't know exactly what level of software I was running. Oh..and guess what... FDR only takes a couple of hours to install (if that). Some of the people on this list keep telling us to get over ourselves and we probably need to. The IT world has changed a lot in the last 20 years but this platform really hasn't for the most part. Putting windows GUIs and web wizard front ends to everything doesn't cut it because the underlying processes are still too complex and old-timer experience is still needed when there is a problem. My 2 cents... Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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 CLOSE failure problem
Everyone, I thought a quick status update might help the curious. IBM has a slip trap dump of the region after the bad close call is made. They have been looking at it for almost a week now. It currently still baffles them. I'm hoping they make progress this week. Mark -- 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: Non-SMP/e packaging
Russell, I would suggest that you decline the request and say that since CA-1 interacts and is IBM module dependent it is in the best interest of all parties to be in a deliverable state which facilitates IBM maintenance. Ed On Sep 11, 2006, at 11:12 PM, Russell Witt wrote: I had a request from a client today, asking when CA-1 would stop being delivered in SMP/e format and would be a simple library-download. From my other talks with clients, I thought everyone wanted products delivered in SMP/e format. And this was the first time I had seen a request to go backwards to simply giving people a loadlib that they could refresh on a monthly/quarterly basis as required. This client pointed to a number of other products that do not use SMP/e and he felt SMP/e way to cumbersome to deal with (obviously, he was in charge of OEM products and not maintenance to the operating system itself). Still, I have to ask, would clients prefer to have an optional non-SMP/e installation procedure even when it means having to download a fresh copy of the product in order to apply maintenance? I am not saying I can change the packaging of CA-1 by myself, but if many clients are interested it is something I can push for. I have just never seen a request like this before. Russell Witt CA-1 Level-2 Support Manager -- 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: Non-SMP/e packaging
On 11 Sep 2006 21:12:29 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (Russell Witt) wrote: I had a request from a client today, asking when CA-1 would stop being delivered in SMP/e format and would be a simple library-download. From my other talks with clients, I thought everyone wanted Even if we limit ourselves to sysprogs, I'm not sure if there's *anything* that *everyone* wants. products delivered in SMP/e format. And this was the first time I had seen a request to go backwards to simply giving people a loadlib that they could refresh on a monthly/quarterly basis as required. This client pointed to a number of other products that do not use SMP/e and he felt SMP/e way to cumbersome to deal with (obviously, he was in charge of OEM products and not maintenance to the operating system itself). Still, I have to ask, would clients prefer to have an optional non-SMP/e installation procedure even when it means having to download a fresh copy of the product in order to apply maintenance? For some products, this can make sense. I don't think that CA-1 is one of them. I've seen some vendor(s) effectively do both: They give the user replacement loadlibs *and* replacement SMP datasets. If an emergency comes up between distro cycles, they can send a PTF, but otherwise the user never has to use SMP. IMO, this should be reserved for fully self-contained products that are not expected to be in LNKLST, LPA, etc. I prefer to apply the maintenance, myself. In some cases, it can be good to have the fine control of APPLYing some fixes and not others. But, I can understand that some people would enjoy the ease of copy these libraries and you're done. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot 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: Non-SMP/e packaging
How many times have we seen an ISV's SMPE install that is simply an IEBCOPY unload and their CSI is less than acceptable. I have time and time again --- CA is a big culprit here had to manually go into the Receive sourcee and tweak their SYSMODs due to not even attempting to validate PREREQ/COREQ checking. If a Vendor is not going to use SMPE as it is supposed to be used, don't even bother trying, I would rather just have an unload file and move on. Having to debug their code and also debug their SMPE logic is a waste of my time. And no, reporting the errors to them does not help. -- 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: Non-SMP/e packaging
Well said, it is impossible to replace 30+ years of experience and feel for the box with a GUI or equivalent dumbed-down product. Old (at 48) Timer. I would hope 99% of us who have worked on this platform know and understand the benifits of SMP/E. I personally would choose an SMP/E install if I can over a non-SMP/E install but that may just be my old-timer prejudice showing. I think what is important is to know exactly what level of software you are running to help in problem determination and to know where do I go from here to upgrade. If vendors distributed well defined levels of their software in run-time only format, this isn't an issue. Some of the people on this list keep telling us to get over ourselves and we probably need to. The IT world has changed a lot in the last 20 years but this platform really hasn't for the most part. Putting windows GUIs and web wizard front ends to everything doesn't cut it because the underlying processes are still too complex and old-timer experience is still needed when there is a problem. My 2 cents... John Cassidy (Dipl.-Ingr.) Berninastrasse 9 8057 Zuerich Europe Telephone: +41 (0) 43 300 4602 Mobile:+41 (0) 79 207 3268 E-Mail: [EMAIL PROTECTED] http://www.JDCassidy.net http://www.europeunited.org http://en.wikipedia.org/wiki/Europe_United John Cassidy (Dipl.-Ingr.) Berninastrasse 9 8057 Zuerich Europe Telephone: +41 (0) 43 300 4602 Mobile:+41 (0) 79 207 3268 E-Mail: [EMAIL PROTECTED] http://www.JDCassidy.net http://www.europeunited.org http://en.wikipedia.org/wiki/Europe_United -- 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: Jcl
On 11 Sep 2006 21:31:56 -0700, [EMAIL PROTECTED] (Brain) wrote: I have a requirement in which based on the day we need to execute the step ie for eg if it is monday then we need to execute the sep2 or else or other days we need to skip this step and execute the other step/ Please any one how this can be coded in the jcl One easy way is to have a program give 7 different return codes, and check for those for your JCL logic. -- 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: Non-SMP/e packaging
On Tue, 12 Sep 2006 09:02:23 -0500, Ed Gould [EMAIL PROTECTED] wrote: I would suggest that you decline the request and say that since CA-1 interacts and is IBM module dependent it is in the best interest of all parties to be in a deliverable state which facilitates IBM maintenance. It has been a long time since I did anything with CA-1, but I don't remember it ever having IFREQs on IBM maintenance, or even going into the same zone or belonging to Z038. Unless I am mistaken, Ed's comment doesn't apply. All it takes to nullify the advantages of an SMP/E installation is *one* request from the vendor to apply service with BYPASS(ID). That said, my preference has generally been for an SMP/E install, provided that it is done correctly. This is no trivial matter, and as Mark pointed out. Innovation does a fine job without it. I wouldn't ask them to divert resources from product development to provide proper SMP/E packaging. Tom Marchant -- 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: Non-SMP/e packaging
Being an ex-sysprog and now a developer I go for SMP/E every time (and I haven't got *that* many grey hairs...) There is a small amount of extra pain to setup the environment in the first place - but after that the benefits way exceed any issues. From a development point of view, SMP/E helps me make sure that when I ship a PTF that I am hitting all of the objects that I intend to. Maybe development shops with fancy source-control software feel comfortable without - personally I need the belt and braces of both what SCLM *and* SMP/E tell me. Without SMP/E - I would probably go for some sort of full library replacement technique (maybe with some sort of build number) and I can see how that might work quite well for small self-contained products. As for supplying individual member replacements outside of SMP/E - it sorta makes me shudder. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] http://www.rs.com/portfolio/mxi/ -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: 12 September 2006 09:49 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non-SMP/e packaging I would hope 99% of us who have worked on this platform know and understand the benifits of SMP/E. I personally would choose an SMP/E install if I can over a non-SMP/E install but that may just be my old-timer prejudice showing. Trying to keep an open mind... Excluding major components (OS, subsystems like CICS/DB2/IMS etc.), would it really be that bad if you just replaced the run time libs when you needed to upgrade / put on maintenance? Since almost all shops have high speed internet access and vendors have electronic downloads, think of all the time and DASD (even though DASD is cheap) you would save by not having to deal with an SMP/E environment and distribution libs. I hate to say it - but think win-doze, PFCSKs, zNextGen. Think of a small shop with few support people. If we truly want to attract new comers to this platform (or at least keep the existing install base) and make it easier and quicker to install and maintain software, this may be a fine alternative to SMP/E for many products. I think what is important is to know exactly what level of software you are running to help in problem determination and to know where do I go from here to upgrade. If vendors distributed well defined levels of their software in run-time only format, this isn't an issue. A perfect example is Innovation's FDR. I have used it in virtually every shops I've been at for 20+ years. I have never missed having an SMP/E install nor have I had any issues / problems related to problem determination because I didn't know exactly what level of software I was running. Oh..and guess what... FDR only takes a couple of hours to install (if that). Some of the people on this list keep telling us to get over ourselves and we probably need to. The IT world has changed a lot in the last 20 years but this platform really hasn't for the most part. Putting windows GUIs and web wizard front ends to everything doesn't cut it because the underlying processes are still too complex and old-timer experience is still needed when there is a problem. My 2 cents... Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: Jcl
On 12 Sep 2006 05:54:23 -0700, [EMAIL PROTECTED] (Graeme Gibson) wrote: Will the job always be submitted on the same day it's supposed to run? Will it run on the machine it's submitted on? However submitted, how confident are you that the job will *always* start within the day it belongs to? What about situations where production is delayed into the next day? Or run at a DR site? Or run at a DR site in another time-zone? Or re-run in the next day? Or what happens when you want to run several day's production in the one 24 hour period? How important is it if the wrong decision gets made some of the times this job runs? And, more esoterically, what are the boundaries of your production day? Is it a 24 hour day that starts at ? Or at 0800? Or something else? All of the above fit in quite nicely to the concept of having a program return a return code.That's the nature of programs. -- 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: Non-SMP/e packaging
On Tue, 2006-09-12 at 09:50 -0500, Tom Marchant wrote: Innovation does a fine job without it. I wouldn't ask them to divert resources from product development to provide proper SMP/E packaging. Of course, this would be an effort *much* larger than simply providing proper packaging. IDP would have to adapt its internal change management procedures to coexist with SMP -- probably an awful lot of work and local development upheaval. -- 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: Non-SMP/e packaging
On Tue, 12 Sep 2006 09:50:10 -0500, Tom Marchant wrote: On Tue, 12 Sep 2006 09:02:23 -0500, Ed Gould wrote: I would suggest that you decline the request and say that since CA-1 interacts and is IBM module dependent it is in the best interest of all parties to be in a deliverable state which facilitates IBM maintenance. It has been a long time since I did anything with CA-1, but I don't remember it ever having IFREQs on IBM maintenance, or even going into the same zone or belonging to Z038. Unless I am mistaken, Ed's comment doesn't apply. All it takes to nullify the advantages of an SMP/E installation is *one* request from the vendor to apply service with BYPASS(ID). That said, my preference has generally been for an SMP/E install, provided that it is done correctly. This is no trivial matter, and as Mark pointed out. Innovation does a fine job without it. I wouldn't ask them to divert resources from product development to provide proper SMP/E packaging. My experience must predate Tom's - I certainly do remember UCC-1 maintenance PRE-ing IBM PTFs (for Open/Close/EOV/etc.). However, that was a long, long, long time ago and Russell's current methods might well no longer need that. I do not, for example, recall having PTF issues with CA- 1 in the slightly more recent past. And I am not now a CA-1 customer so I (a) can't say and (b) don't have a vote. But if Russell believes he can ship working code with or without SMP/E, I believe him. My present work location has contract requirements that ALL software must be installed via SMP/E (if SMP/E is at all an option). Software that is not available via SMP/E is generally not allowed here. -- Tom Schmidt Madison, WI -- 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: Fw: Non-SMP/e packaging
As for other vendors shipping (only) non-SMP format, that's generally because they have no idea of how to package their product. Perhaps true for some vendors but not Innovation. Our modules don't intersect or depend on any IBM modules, so the checking done by SMP is not useful. These days most of our distributions are by email or FTP. The product libraries can be installed in 5 minutes and the only other required step is to authorize the load library with a console command. Try that with SMP. Our maintenance is in the form of zaps, which apply easily without SMP -- 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: Non-SMP/e packaging
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Andrews Sent: Tuesday, September 12, 2006 10:16 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non-SMP/e packaging snip Of course, this would be an effort *much* larger than simply providing proper packaging. IDP would have to adapt its internal change management procedures to coexist with SMP -- probably an awful lot of work and local development upheaval. snip In a certain company's case, the change to SMP/E support allowed them to go to source level maint. The number of fixes done by ZAP that some how never got converted to source was a thorn in their side. In that case, going to SMP/E based support was both simple and greatly desired (internally) and answered a request by several of their customers. However, your point is quite right. For certain companies with certain products, it would take some time to change (with quite some effort) to a change control system to match to the APAR/PTF scheme needed by SMP. And it may not even be possible to change their current system so that they would have to develop a new system. And while doing this, they would have to make sure they didn't break things for their currently supported products and customers. A conundrum. Later, 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: Non-SMP/e packaging
Mark Zelden wrote: [...] A perfect example is Innovation's FDR. I have used it in virtually I have never heard complaints about FDR support, etc. Is seems that SMP/E is not crucial to it. People discuss about *binary* alternatives: SMP/E or library unload. I think there are other ways to manage the code. Even SMP/E could be simpler. Current conceptions are for historical reasons, not because of real needs. Compromise between history and usability makes SMP/E difficult to understand and then cumbersome. Why don't we think about SMP2 - new approach, totally free of old junk. 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
Re: Non-SMP/e packaging
In a message dated 9/12/2006 11:03:25 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Why don't we think about SMP2 - new approach, totally free of old junk. My $0.02 Well, if you're willing to accept the consequences. One of the local insurance companies signed onto auto-maint with AS/400 and got bit a couple years back when it destroyed their production data. They were only down 72 hours while the Marketing rep downloaded the updated CD and drove 60 miles to do the upgrade/ reinstall. -- 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
Question : VTOC size - JES2 Volume
Can anybody please correct me if I am wrong. I have to init a volume for JES2 HASPACE. The volume is a 3390 -3 . Below are my parms for the VTOC. VTOC(0,1,29) INDEX(2,0,45) Is that okay? - Get your own web address for just $1.99/1st yr. We'll help. Yahoo! Small Business. -- 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: Non-SMP/e packaging
On Tue, 12 Sep 2006 18:02:49 +0200, R.S. [EMAIL PROTECTED] wrote: Why don't we think about SMP2 - new approach, totally free of old junk. My $0.02 See http://www.freepatentsonline.com/6715144.html to find out what Greg Daynes and company are thinking about. Doug -- 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: garlic.com
tony babonas wrote: Whatever their site is I'm deeply envious of how comprehensive its contents are. The design must be such that: 1. It's readily update-able. 2. It's readily search-able, in that a reference to the 1978 version of the ABC Frammis get quoted rather instantly. 3. Seeming non-redundant, though I must admit I only read a few additional peripheral links. Anyway, it impresses me... as noted here http://www.garlic.com/~lynn/index.html much of the website information is maintained in some technology that i originally worked on about the same time I was doing some system/r stuff (original relational/sql) http://www.garlic.com/~lynn/subtopic.html#systemr which i've since rewritten from scratch a number of times. the information is maintained and managed in the technology and then (static) html files are periodically regenerated and changes copied to the garlic web pages. as i've mentioned a number of times before (and also referenced in the attached comments) most of the html files have an exceptionally high ratio of hrefs to amount of content (as well as attempting to simulate bi-directional links) ... which possibly is the reason that many of the major web crawlers appear to use it for regression case (hits to all the files from the same crawlers several times per day). the ietf index http://www.garlic.com/~lynn/rfcietff.htm and note on the merged taxonomies and glossaries http://www.garlic.com/~lynn/index.html#glosnote for instance ... the privacy taxonomy/glossary was done in support of working as co-author of the x9.99 financial standard i.e. notes on various merged taxonomies and glossaries Payment Terms merged from: ACH, FACSNET, FRBC, FRBM, FRBSF, GAO, NSCC, and misc. http://www.garlic.com/~lynn/payment.htm Security Terms merged from: AFSEC, AJP, CC1, CC2, CC21 (CC site), CIAO, FCv1, FFIEC, FJC, FTC, IATF V3 (IATF site), IEEE610, ITSEC, Intel, JTC1/SC27 (SC27 site), KeyAll, MSC, NIST 800-30, 800-33, 800-37, 800-53, 800-61, 800-77, 800-83, FIPS140, NASA, NCSC/TG004, NIAP, NSA Intrusion, CNSSI 4009, online security study, RFC1983, RFC2504, RFC2647, RFC2828, TCSEC, TDI, TNI, vulnerability testing and misc. Updated 20060701 with NIST IR 7298 Glossary containing terms from the following FIPS documents: 140-2, 181, 185, 188, 191, 196, 197, 198, 200, 201; and the following 800 documents: 12, 15, 16, 18, 19, 21, 24, 26, 27, 28, 30, 32, 33, 34, 35, 36, 37, 38, 40, 41, 44, 46, 47, 48, 49, 50, 53, 55, 56, 57, 58, 59, 60, 61, 63, 64, 65, 66, 67, 72, 79, 83, 88, 90 http://www.garlic.com/~lynn/secure.htm Privacy Privacy terms from merged Security Taxonomy Glossary combined with EU-DPD, FTC, GLBA, HIPAA, OECD, and OMB. Updated 20040222 with terms from OMB. Somewhat related, X9.99, Privacy Impact Assessment standard is now also available at ANSI X9.99 http://www.garlic.com/~lynn/privacy.htm X9F Terms merged from X9F document glossaries: WD15782, X509, X9.8, X9.24, X9.31, X9.42, X9.45, X9.49, X9.52, X9.62, X9.65, X9.69. Terms from ABA/ASC X9 TR1-1999 replace terms from X9F TG-16 glossary (identified by lower case x9 instead of upper-case X9). Original source documents include: X3.92, X3.106, x9.1, x9.5, x9.6, x9.8, x9.9, x9.17, x9.19, x9.23, x9.24, x9.26, x9.28, x9.30, x9.31, x9.41, x9.42, x9.44, x9.45, x9.49, x9.52, x9.55, x9.57, x9.62, x9.69 x9.74, x9.76, x9.78, x9.80, x9.82, and TG-17. http://www.garlic.com/~lynn/x9f.htm Financial Warning: Not for light of heart, the combined glossary and taxonomy is over 3.5 megabytes and has been known to lock up some browser versions on some platforms (more because of the number of links than size of files). There are 6600 terms, 8500 definitions and 35,500 href links. Terms merged from Payment Taxonomy Glossary with Bureau of Economic Analysis, Chicago Board of Trade, Commodity Futures Trading Commission, C Harvey at Duke (Copyright, for non-commercial use only), Environmental Protection Agency, Federal Deposit Insurance Corporation, International Trade Data System, International Trade Resource Center, MidAmerica Commodity Exchange, New York Merchantile Exchange, New York Stock Exchange, Office Thrift Supervision, Securities Exchange Commission, Treasury Management Association of Canada, UN Office on Drugs and Crime and Western Connecticut State University. Updated 20050320 with FIDC international terms http://www.garlic.com/~lynn/financial.htm -- 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: Question : VTOC size - JES2 Volume
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of willie bunter Sent: Tuesday, September 12, 2006 11:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Question : VTOC size - JES2 Volume Can anybody please correct me if I am wrong. I have to init a volume for JES2 HASPACE. The volume is a 3390 -3 . Below are my parms for the VTOC. VTOC(0,1,29) INDEX(2,0,45) Is that okay? snip I would make the VTOC 1 track with NO index. The only file on the volume will be the HASPACE, right? So a minimal VTOC is all that is needed. Later, 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: Non-SMP/e packaging
Ed Finnell wrote: In a message dated 9/12/2006 11:03:25 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Why don't we think about SMP2 - new approach, totally free of old junk. My $0.02 Well, if you're willing to accept the consequences. One of the local insurance companies signed onto auto-maint with AS/400 and got bit a couple years back when it destroyed their production data. They were only down 72 hours while the Marketing rep downloaded the updated CD and drove 60 miles to do the upgrade/ reinstall. What consequences ? Why do you think the new solution will be bad ? Having that DB2 would never appear, the same for almost any new thing in IT. Sometimes I observe such approach: do not touch anything. Usually problems arise when the change is a must, i.e. WLM goal mode. -- 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: Question : VTOC size - JES2 Volume
Steve's idea makes sense. I have been using MAP VTOC(0,7,8) INDEX(0,1,6), which occupies the rest of cyl 0 and then allocate the HASPACE as 3338 cyls. Either way, maximize your space by minimizing the VTOC. David Mueller | Systems Programmer | DMS/EITS Phone: 850-414-9134 (Rm 107 SRC) | Fax: 850-921-8343 E-mail: [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Thompson, Steve (SCI TW) Sent: Tuesday, September 12, 2006 12:15 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Question : VTOC size - JES2 Volume -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of willie bunter Sent: Tuesday, September 12, 2006 11:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Question : VTOC size - JES2 Volume Can anybody please correct me if I am wrong. I have to init a volume for JES2 HASPACE. The volume is a 3390 -3 . Below are my parms for the VTOC. VTOC(0,1,29) INDEX(2,0,45) Is that okay? snip I would make the VTOC 1 track with NO index. The only file on the volume will be the HASPACE, right? So a minimal VTOC is all that is needed. Later, 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 -- 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: Question : VTOC size - JES2 Volume
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of willie bunter Sent: Tuesday, September 12, 2006 11:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Question : VTOC size - JES2 Volume Can anybody please correct me if I am wrong. I have to init a volume for JES2 HASPACE. The volume is a 3390 -3 . Below are my parms for the VTOC. VTOC(0,1,29) INDEX(2,0,45) Is that okay? Why bother? If the volume is dedicated to JES2 spool (i.e. only one dataset), then I'd make the VTOC(0,1,14) with no index at all. That leaves the rest of the volume for the dataset. You could even go to VTOC(0,1,1). There is no need for an index at all. An index is only useful if you have a large number of VTOC I/Os going on. On this volume, once JES2 has OPEN'ed the HASPACE dataset, the VTOC should not be hit again until the next JES2 restart. -- 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: Question : VTOC size - JES2 Volume
Just a heads up for people working with large volumes and small vtocs and vtoc indexes APAR OA16512 fixes a problem we encountered with ICKDSF for a 3390-9 volume which had a 1 track vtoc and 1 track vtoc index. Brian On Tue, 12 Sep 2006 12:15:00 -0400, Thompson, Steve (SCI TW) wrote: -Original Message- From: On Behalf Of willie bunter Sent: Tuesday, September 12, 2006 11:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Question : VTOC size - JES2 Volume Can anybody please correct me if I am wrong. I have to init a volume for JES2 HASPACE. The volume is a 3390 -3 . Below are my parms for the VTOC. VTOC(0,1,29) INDEX(2,0,45) Is that okay? snip I would make the VTOC 1 track with NO index. The only file on the volume will be the HASPACE, right? So a minimal VTOC is all that is needed. Later, 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: Question : VTOC size - JES2 Volume
In a message dated 9/12/2006 11:24:14 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: If the volume is dedicated to JES2 spool (i.e. only one dataset), then I'd make the VTOC(0,1,14) with no index at all. That leaves the rest of the volume for the dataset. You could even go to VTOC(0,1,1). There is no need for an index at all. An index is only useful if you have a large number of VTOC I/Os going on. On this volume, once JES2 has OPEN'ed the HASPACE dataset, the VTOC should not be hit again until the next JES2 restart. If you're going to have only a one-track VTOC in cylinder 0 and the rest of the volume dedicated to SYS1.HASPACE allocated by cylinders, why not put a small VTOC index in cylinder 0 along with the small VTOC? There might be a metadata reason why it's better to have an indexed VTOC on all volumes. E.g., some day all volumes might have to be SMS-managed. Speaking of VTOC hits, does SDSF hit the VTOC when a SYSOUT access begins? Bill Fairchild -- 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: garlic.com
re: http://www.garlic.com/~lynn/2006q.html#25 garlic.com oh, and the e-server magazine article http://www.eservercomputing.com/ME2/Audiences/dirmod.asp?sid=BCF4DE820EA64A858FB46EECB7C00BB4nm=type=Publishingmod=Publications::Articlemid=8F3A7027421841978F18BE895F87F791AudID=174DB902288C4970A30C71C9427313A7tier=4id=BDFBAB466D2F4B27B4EDB579BED7D89E as an aside to the comment about having been around ... my wife served her time also ... worked on FS, was in the gburg JES group (one of the catchers for ASP turning into JES3 ... and worked on a design for merging JES2/JES3 into a single product) ... and then was con'ed into going to POK to be in charge of loosely-coupled architecture. while there she did peer-coupled shared data architecture http://www.garlic.com/~lynn/subtopic.html#shareddata except for the IMS hot standby effort ... didn't see a lot of uptake until parallel sysplex. recent posting of old email in a.f.c newsgroup mentioning patent she got on token protocol while she was doing her stint in POK http://www.garlic.com/~lynn/2006q.html#24 -- 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: Question : VTOC size - JES2 Volume
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of (IBM Mainframe Discussion List) Sent: Tuesday, September 12, 2006 11:44 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Question : VTOC size - JES2 Volume snip If you're going to have only a one-track VTOC in cylinder 0 and the rest of the volume dedicated to SYS1.HASPACE allocated by cylinders, why not put a small VTOC index in cylinder 0 along with the small VTOC? There might be a metadata reason why it's better to have an indexed VTOC on all volumes. E.g., some day all volumes might have to be SMS-managed. Speaking of VTOC hits, does SDSF hit the VTOC when a SYSOUT access begins? Bill Fairchild ARG! Yes, I am fairly sure that it does. That's why SDSF is APF authorized. So it can bypass any RACF restrictions on opening HASPACE and HASPCKPT. But I still maintain that if the volume only has a single, permanent, dataset (regardless of what the dataset is), then an INDEX is totally unnecessary unless the volume is SMS managed. I can see this scenario for volumes in a DB2 storage group (few datasets, rarely created, but SMS managed). -- 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
LISTD command
Hello: (This is directed to IBMers or SHARE members who may serve on committees that deal with such matters). Would IBM consider upgrading LISTD's display to include the newer dataset formats under DSORG (e.g., something other than PO for PDS/E, and something other than PS for large and extended datasets). Or is TSO/E code like LISTD stabilized at its present level of support. For what it's worth, I still use LISTD a lot: perhaps others do, also. regards, Joe D'Alessandro -- 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: Jcl
I have a requirement in which based on the day we need to execute the
step
How about:
//DOW EXEC PGM=IKJEFT1A,
// PARM='DOW'
//SYSTSPRT DD DUMMY
//SYSTSIN DD DUMMY
//SYSEXEC DD DISP=SHR,DSN=REXX.LIB
//* /* rexx */
//* lib: REXX.LIB(DOW)
//* exit date('B')//7
//MONDAY EXEC PGM=IEFBR14,COND=(0,NE,DOW)
//TUESDAY EXEC PGM=IEFBR14,COND=(1,NE,DOW)
//WEDNESDA EXEC PGM=IEFBR14,COND=(2,NE,DOW)
//THURSDAY EXEC PGM=IEFBR14,COND=(3,NE,DOW)
//FRIDAY EXEC PGM=IEFBR14,COND=(4,NE,DOW)
//SATURDAY EXEC PGM=IEFBR14,COND=(5,NE,DOW)
//SUNDAY EXEC PGM=IEFBR14,COND=(6,NE,DOW)
Steve Runtsch
**
This e-mail message and all attachments transmitted with it may contain legally
privileged and/or confidential information intended solely for the use of the
addressee(s). If the reader of this message is not the intended recipient, you
are hereby notified that any reading, dissemination, distribution, copying,
forwarding or other use of this message or its attachments is strictly
prohibited. If you have received this message in error, please notify the
sender immediately and delete this message and all copies and backups thereof.
Thank you.
**
--
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
FW: Non-SMP/e packaging
You are thinking back to the days when UCC1 zapped IBM O/C/EOV modules instead of using SVCs and exit points to install their code. With zaps you MUST have the correct level of IBM code so pre-req entries were required. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 My experience must predate Tom's - I certainly do remember UCC-1 maintenance PRE-ing IBM PTFs (for Open/Close/EOV/etc.). However, that was a long, long, long time ago and Russell's current methods might well no longer need that. I do not, for example, recall having PTF issues with CA- 1 in the slightly more recent past. And I am not now a CA-1 customer so I (a) can't say and (b) don't have a vote. But if Russell believes he can ship working code with or without SMP/E, I believe him. My present work location has contract requirements that ALL software must be installed via SMP/E (if SMP/E is at all an option). Software that is not available via SMP/E is generally not allowed here. -- Tom Schmidt Madison, WI -- 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: FW: Non-SMP/e packaging
Exactly right. Back in the good old days when real sysprogs were cowboys and COBOL programmers ran away, scared (and scarred). *smirk* -- Tom Schmidt Madison, WI On Tue, 12 Sep 2006 12:50:56 -0400, Veilleux, Jon L wrote: You are thinking back to the days when UCC1 zapped IBM O/C/EOV modules instead of using SVCs and exit points to install their code. With zaps you MUST have the correct level of IBM code so pre-req entries were required. ...which followed what I wrote: My experience must predate Tom's - I certainly do remember UCC-1 maintenance PRE-ing IBM PTFs (for Open/Close/EOV/etc.). However, that was a long, long, long time ago and Russell's current methods might well no longer need that. I do not, for example, recall having PTF issues with CA- 1 in the slightly more recent past. And I am not now a CA-1 customer so I (a) can't say and (b) don't have a vote. But if Russell believes he can ship working code with or without SMP/E, I believe him. My present work location has contract requirements that ALL software must be installed via SMP/E (if SMP/E is at all an option). Software that is not available via SMP/E is generally not allowed here. -- 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: Non-SMP/e packaging
Russell Witt wrote: I had a request from a client today, asking when CA-1 would stop being delivered in SMP/e format and would be a simple library-download. From my other talks with clients, I thought everyone wanted products delivered in SMP/e format. And this was the first time I had seen a request to go backwards to simply giving people a loadlib that they could refresh on a monthly/quarterly basis as required. This client pointed to a number of other products that do not use SMP/e and he felt SMP/e way to cumbersome to deal with (obviously, he was in charge of OEM products and not maintenance to the operating system itself). Still, I have to ask, would clients prefer to have an optional non-SMP/e installation procedure even when it means having to download a fresh copy of the product in order to apply maintenance? I am not saying I can change the packaging of CA-1 by myself, but if many clients are interested it is something I can push for. I have just never seen a request like this before. A non-SMP/E install can seem desirable to someone without much SMP/E experience (or for whom a re-boot is considered a problem solution), but such an install introduces it's own set of problems, the most serious of which (IMHO) is its inability to call in required fixes for IBM components. The most recent example for us was APAR OA17010 against RMF. That APAR fixed a serious problem with ERBSMFI that would result in a recovery loop when invoked by the current (E)JES release on back-level z/OS systems. Once IBM fixed the problem, we added the requisite IFREQ statements to our SMP/E MCS. We've had similar recent issues over the past couple of years with the z/OS Console Restructure, z990 Exploitation Feature, JES2, JES3, OMVS, and other components. We can distribute our own fixes -- no problem. But, there's just no equivalent method for synchronizing required IBM maintenance when performing a non-SMP/E install! Rather than taking any giant backward leaps (IEBCOPY and ZAPs give me bad dreams), I'm waiting patiently for IBM to finish the z/OS implementation of its cross-platform Solution Installer. That should help relieve any ease of use issues associated with SMP/E while, at the same time, continuing to provide maintenance tracking and cross-component synchronization needed by complex products installed in a robust, mission-critical environment like z/OS. -- 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
FW: FW: Non-SMP/e packaging
I have nothing but respect for UCC1. It was my path from application programming to systems programming. Most of the applications folks I worked with have either retired or been replaced with offshore programmers. I have no complaints! Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Schmidt Sent: Tuesday, September 12, 2006 1:05 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: FW: Non-SMP/e packaging Exactly right. Back in the good old days when real sysprogs were cowboys and COBOL programmers ran away, scared (and scarred). *smirk* -- Tom Schmidt Madison, WI On Tue, 12 Sep 2006 12:50:56 -0400, Veilleux, Jon L wrote: You are thinking back to the days when UCC1 zapped IBM O/C/EOV modules instead of using SVCs and exit points to install their code. With zaps you MUST have the correct level of IBM code so pre-req entries were required. ...which followed what I wrote: My experience must predate Tom's - I certainly do remember UCC-1 maintenance PRE-ing IBM PTFs (for Open/Close/EOV/etc.). However, that was a long, long, long time ago and Russell's current methods might well no longer need that. I do not, for example, recall having PTF issues with CA- 1 in the slightly more recent past. And I am not now a CA-1 customer so I (a) can't say and (b) don't have a vote. But if Russell believes he can ship working code with or without SMP/E, I believe him. My present work location has contract requirements that ALL software must be installed via SMP/E (if SMP/E is at all an option). Software that is not available via SMP/E is generally not allowed here. -- 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: Non-SMP/e packaging
A Marketing rep? Well, there's your problem. A sysprog would have had the download done and the 60 miles driven in 2 or 3 minutes and would have used a flashlight and a magnifying glass to fix errors on the CD. Jon snip Well, if you're willing to accept the consequences. One of the local insurance companies signed onto auto-maint with AS/400 and got bit a couple years back when it destroyed their production data. They were only down 72 hours while the Marketing rep downloaded the updated CD and drove 60 miles to do the upgrade/ reinstall. /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: Question : VTOC size - JES2 Volume
On 12 Sep 2006 09:15:08 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (Thompson, Steve , SCI TW) wrote: Can anybody please correct me if I am wrong. I have to init a volume for JES2 HASPACE. The volume is a 3390 -3 . Below are my parms for the VTOC. VTOC(0,1,29) INDEX(2,0,45) Is that okay? snip I would make the VTOC 1 track with NO index. The only file on the volume will be the HASPACE, right? So a minimal VTOC is all that is needed. I agree that there's no need for an index. However, I'm ambivalent on VTOC(0,1,1) vs. VTOC(0,1,14). The latter keeps everything on cylinder boundaries. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot 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: Non-SMP/e packaging
In a message dated 9/12/2006 12:21:46 P.M. Central Standard Time, [EMAIL PROTECTED] writes: A Marketing rep? Well, there's your problem. A sysprog would have had the download done and the 60 miles driven in 2 or 3 minutes and would have used a flashlight and a magnifying glass to fix errors on the CD. That's the beauty of downsizing. don't have to worry with no high-end sysprogs anymore just let the machine do the work! Until it breaksand then teflon blades recommended on all circulating apparatus. No more designated blamees to point tovbsg. -- 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: Non-SMP/e packaging
Cole Software ships its z/XDC product in an SMP/E package, but we've made some unusual philosophical choices that result in a considerably simplified installation process as compared to the operating system and to most other products. Background: SMP/E is designed to support an incremental maintenance philosophy for huge and hugely complex software structures (the entire operating system, and its myriads or subproducts, for example). Incremental? - You RECEIVE and APPLY new maintenance to a software base. - If you don't like it, you can RESTORE the base and then REJECT the maintenance. - But if you do like it, you can then ACCEPT the maintenance and, thereby, establish a NEW BASE for subsequent maintenance. So the base to which you RECEIVE and APPLY maintenance increments over time. And once maintenance has been ACCEPT'd into the base, you CANNOT remove it. All you can do is to RECEIVE, APPLY and ACCEPT superseding maintenance. Supporting an incremental maintenance philosophy for complex and fluidly interrelated software systems requires complex capabilities. It's simply in the nature of the beast, so there is no way to keep both SMP/E and the maintenance process itself from being complex. The major reason why Cole Software packages z/XDC with SMP/E is that it makes the management of post-release maintenance very simple for me, and it makes the installation of maintenance trivially simple for our customers. Also, it leads our customers to use an installation process that is uniform across our customer base, and from a support standpoint, that is extremely valuable. But there are two things that we've done to our SMP/E process that are, perhaps, unique and that extensively simplify the process both for ourselves and for our customers. Both of these characteristics are made possible by the fact that, from an installation issues point of view, z/XDC is pretty simple. (They would not work for complex products with complex interrelations with other products.) First, we follow a cumulative methodology (not an incremental one) for our maintenance. This means the following: (a) Every maintenance file that we publish contains all maintenance, accumulated since the product's release date. The nice thing about this is that when a customer needs to apply a year or two's worth of back maintenance, all he has to do is download, RECEIVE and APPLY just one maintenance file. That's all. (b) This requires the customer never to ACCEPT z/XDC maintenance. Why not? Because the cumulative maintenance file is always designed to fit the product as it was originally installed. If an ACCEPT were to be done, then the installation libraries would be irretrievably changed such that the maintenance file would no longer fit. (c) So the maintenance job we provide does the following: RESTORE: This removes prior maintenance from the TLIBs, restoring them to their initial installation state. REJECT: This removes the prior maintenance data from SMP/E's database. RECEIVE: This introduces the new maintenance file into SMP/E's database. APPLY: This applies the new maintenance to z/XDC's TLIBS. Second, we are able to insure that all dependances that z/XDC might have, either on Operating System capabilities or on other products, are resolved at EXECUTION time, not at installation time. By doing this, we are then able to require our customers to NOT install z/XDC into there existing SMP/E libraries, but instead to create an entirely independent set of SMP libraries (CSI, PTS, etc.) devoted solely to z/XDC! The benefits of this are profound: (1) Waste of disk space? NOT! After initial installation, the z/XDC-dedicated SMP database and libraries start out at 30 tracks. Ok, allowing reasonable space for expansion, it might be better to allocate a hundred or so (at most!). (2) Since z/XDC's SMP/E datasets are independent from the rest of the system, we can impose optional settings that (a) are specific to z/XDC's maintenance needs and (b) are uniform across our customer base and (c) do not conflict with the needs of other products. (3) Since the SMP/E datasets are independent and uniform, we can provide canned JCL for our customers to use that work right out of the box to: (a) Purge older SMP/E datasets (CSI, PTS, etc.) and product installation libraries (DLIBs and TLIBs) (b) Create new ones (c) Establish all needed SMP/E definitions and settings (d) Install the product into new TLIBs and DLIBs (e) Apply all accumulated maintenance This is a suite of four jobs that take a grand total of four minutes to run (even on a flop-top system such as ours!). (4) Since the SMP/E process is uniform and the SMP/E phase jobs are all canned, the installing programmer can run a successful install with no (zero
Re: JCL
On 12 Sep 2006 09:41:19 -0700, [EMAIL PROTECTED] wrote:
Top posted:That looked interesting - I haven't ever run anything
like that, so I tested it and got:
IEF212I ZHBDOW DOW SYSEXEC - DATA SET NOT FOUND
IEF272I ZHBDOW DOW - STEP WAS NOT EXECUTED.
Too bad.
I have a requirement in which based on the day we need to execute the
step
How about:
//DOW EXEC PGM=IKJEFT1A,
// PARM='DOW'
//SYSTSPRT DD DUMMY
//SYSTSIN DD DUMMY
//SYSEXEC DD DISP=SHR,DSN=REXX.LIB
//* /* rexx */
//* lib: REXX.LIB(DOW)
//* exit date('B')//7
//MONDAY EXEC PGM=IEFBR14,COND=(0,NE,DOW)
//TUESDAY EXEC PGM=IEFBR14,COND=(1,NE,DOW)
//WEDNESDA EXEC PGM=IEFBR14,COND=(2,NE,DOW)
//THURSDAY EXEC PGM=IEFBR14,COND=(3,NE,DOW)
//FRIDAY EXEC PGM=IEFBR14,COND=(4,NE,DOW)
//SATURDAY EXEC PGM=IEFBR14,COND=(5,NE,DOW)
//SUNDAY EXEC PGM=IEFBR14,COND=(6,NE,DOW)
Steve Runtsch
**
This e-mail message and all attachments transmitted with it may contain
legally privileged and/or confidential information intended solely for the use
of the addressee(s). If the reader of this message is not the intended
recipient, you are hereby notified that any reading, dissemination,
distribution, copying, forwarding or other use of this message or its
attachments is strictly prohibited. If you have received this message in
error, please notify the sender immediately and delete this message and all
copies and backups thereof.
Thank you.
**
--
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: JCL
You would have to have that named REXX library with the DOW code in it. Daniel McLaughlin ZOS Systems Programmer Crawford Company PH: 770 621 3256 * -- 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: Question : VTOC size - JES2 Volume - Thank You
Thanks to all who have responded. I appreciate your help. Thompson, Steve (SCI TW) [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of willie bunter Sent: Tuesday, September 12, 2006 11:11 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Question : VTOC size - JES2 Volume Can anybody please correct me if I am wrong. I have to init a volume for JES2 HASPACE. The volume is a 3390 -3 . Below are my parms for the VTOC. VTOC(0,1,29) INDEX(2,0,45) Is that okay? I would make the VTOC 1 track with NO index. The only file on the volume will be the HASPACE, right? So a minimal VTOC is all that is needed. Later, 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 - Stay in the know. Pulse on the new Yahoo.com. Check it out. -- 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: Non-SMP/e packaging
On 12 Sep 2006 10:28:29 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (David Cole) wrote: (c) So the maintenance job we provide does the following: RESTORE: This removes prior maintenance from the TLIBs, restoring them to their initial installation state. REJECT: This removes the prior maintenance data from SMP/E's database. RECEIVE: This introduces the new maintenance file into SMP/E's database. APPLY: This applies the new maintenance to z/XDC's TLIBS. snip I suspect that many (if not most) commercial products would benefit from taking an approach such as ours. Please don't encourage this misuse of SMP. I like your product, but this technique is contrary to the spirit of SMP. Therefore, it causes cognitive dissonance in some of us who do understand SMP, and wish to use it correctly. Since the technique is different from what I'm used to, it takes longer than if it were the normal, complicated SMP install of maintenance. ACCEPT, (Optionally REJECT,) RECEIVE, APPLY is the normal route for mass maintenance, and takes very little time or thought, as long as the maintenance is packaged correctly. Since many sysprogs are just SMP jockeys, is it too much to ask that they be able to use SMP? If they can, then there should be no need to simplify things for them. N.B. Please note the quotes around 'just', above. Those are scare quotes, not greengrocer quotes, and I mean no disparagement towards competent SMP jockeys. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot 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: Question : VTOC size - JES2 Volume
I agree that there's no need for an index. However, I'm ambivalent on VTOC(0,1,1) vs. VTOC(0,1,14). The latter keeps everything on cylinder boundaries. To what advantage? HASPACE is always allocated in cylinders so it will start on cylinder 1 regardless of the VTOC size. Making the VTOC 1 track will (marginally) improve the performance of programs which must scan the VTOC, such as FDR and DSS. -- 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: Where is the DB2-L List?
So How does one go about subscribing to this list? All my attempts to send email to [EMAIL PROTECTED] keep bouncing . As follows: [EMAIL PROTECTED] (Message relaying to this domain disabled) /s/ tuco bonno graduate, College of Conflict Management University of Southeast Asia I partied on the Ho Chi Minh trail -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mike Bell Sent: Friday, 08 September, 2006 19:06 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Where is the DB2-L List? DB2 listserv moved to the IDUG servers several years ago - someone else may remember exactly when but it is now the correct address. or [EMAIL PROTECTED] -- Mike -- 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: Non-SMP/e packaging
On Tue, 12 Sep 2006 13:26:50 EDT Ed Finnell [EMAIL PROTECTED] wrote: :In a message dated 9/12/2006 12:21:46 P.M. Central Standard Time, :[EMAIL PROTECTED] writes: :A Marketing rep? Well, there's your problem. A sysprog would have had the :download done and the 60 miles driven in 2 or 3 minutes and would have used :a flashlight and a magnifying glass to fix errors on the CD. :That's the beauty of downsizing. don't have to worry with no high-end :sysprogs anymore just let the machine do the work! Until it breaksand :then teflon blades recommended on all circulating apparatus. No more :designated blamees to point tovbsg. I don't think you can qualify as a true system programmer unless you (1) do something that causes the system to loop/crash and (2) you use the manual screen to fix memory so that an IPL is not needed -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question : VTOC size - JES2 Volume
I think that most of the non-cylinder allocated dataset problems went away with ECKD. I remember in the past that if a dataset was non-cylinder allocated, then the CCW string used by access method would not be able to use the search this cylinder for the record opcode, but would need to search each track individually because the dataset __might__ not end on a cylinder boundry. IIRC, with ECKD, the access method does a define extent to set up the range of tracks for I/O and the control unit will abort any attempt to get outside that extent. So the access method (just can't remember which one!) can feel free to use multitrack searching. Actually, not quite true. There is a flag in the DEFINE EXTENT CCW that says that this chain was converted from CKD. If set, multi-track search chains still stop at the end of every cylinder. The flag is set for chains uses by access methods such as SAM, PAM, DAM. -- 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: Question : VTOC size - JES2 Volume
On Tue, 12 Sep 2006 12:43:38 EDT, IBM Mainframe Discussion List [EMAIL PROTECTED] wrote: some day all volumes might have to be SMS-managed. Ha! I'd like to see you try to catalog SYS1.HASPACE. Tom Marchant -- 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
Password expiration message?
John McKown asked a question about login password messages What about people (we are few) who use telnet, or rlogin, or ssh to get into a UNIX shell? I don't recall it ever putting out this sort of message either. John, I do not remember seeing any response to this. If you did get an answer, we would be interested in what you found out. Thanks, Jimmy -- 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: Where is the DB2-L List?
Here are the instructions from the DB2-L list. Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select Join or Leave the list. The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [EMAIL PROTECTED] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm - -- 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
Password expiration message?
John McKown asked a question I can't remember if this happens or not. On TSO, when you logon and your password is about to expire, you get a message like: ICH70002I YOUR PASSWORD WILL EXPIRE IN 1 DAYS. Does the ftp server send out this message? Sorry, but I just don't remember. And I just changed my password, so it will be a while before I can check again. We have a number of ftp-only users. Is there any way to get the ftp server to send this message to the ftp client (as a 230 message, perhaps). Or can I use the FTPCHKPWD exit to do this. If so, anybody got code? grin. What about people (we are few) who use telnet, or rlogin, or ssh to get into a UNIX shell? I don't recall it ever putting out this sort of message either. I do not remember seeing any response. John, if you have recieved an answer we would be interested also. -- 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: JCL
On 12 Sep 2006 11:55:52 -0700, [EMAIL PROTECTED] wrote:
Use your lib name for rexx.lib
OK, I see it now.
EDIT D44201.REXX.LIB(DOW)
Command ===
**
01 /* REXX */
02 EXIT DATE('B')//7
...
//DOW EXEC PGM=IKJEFT1A,
// PARM='DOW'
//SYSTSPRT DD DUMMY
//SYSTSIN DD DUMMY
//SYSEXEC DD DISP=SHR,DSN=D44201.REXX.LIB(DOW)
//* /* REXX */
//* LIB: D44201.REXX.LIB(DOW)
//* EXIT DATE('B')//7
//MONDAY EXEC PGM=IEFBR14,COND=(0,NE,DOW)
Except it returns:
ZHBDOW DOW - STEP WAS EXECUTED - COND CODE 0012
D44201.REXX.LIB KEPT
VOL SER NOS= DBS920.
So step Tuesday doesn't run.
--
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
Format 2 save area?
(x-posted to IBM-MAIN and ASSEMBLER-LIST) I was researching an abend in Unicode translation services code that I brought upon myself (bad length passed), and have since fixed. However, I ran into something interesting that I could not find any explanatory doc. I was looking at R13 in the RTM2WA and voila - I see F2SA in save area + 4. So off to the bookshelves and I can find references to F4SA, F5SA, F6SA, F7SA, as well as the old reliable F1SA. But no F2SA (or F3SA if that matters). I've searched IBM-MAIN and ASSEMBLER-LIST archives. I've found some descriptions of F4 and F5, but not F2. I've also searched the IBM libraries (to z/OS 1.8), as well as SYS1.MACLIB and MODGEN but I have not been rewarded for my endeavours. Has anyone ran into this before? Peter Relson, any comments? (I found your great detailed explanations of F4 and F5 from 4 years ago.) Thanks, 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 -- 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: JCL
From: Howard Brazee [EMAIL PROTECTED] //DOW EXEC PGM=IKJEFT1A, // PARM='DOW' //SYSEXEC DD DISP=SHR,DSN=D44201.REXX.LIB(DOW) ZHBDOW DOW - STEP WAS EXECUTED - COND CODE 0012 You have PARM='DOW' specified on line 2 above, and REXX.LIB(DOW) specified on the SYSEXEC. Either remove the parm or remove the member name; you need one or the other, but not both. Dave Salt SimpList(tm) - The easiest, most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm -- 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: Question : VTOC size - JES2 Volume
Tom Marchant wrote: On Tue, 12 Sep 2006 12:43:38 EDT, IBM Mainframe Discussion List [EMAIL PROTECTED] wrote: some day all volumes might have to be SMS-managed. Ha! I'd like to see you try to catalog SYS1.HASPACE. Why not ? It is currently impossible (to catalog *all* the SYS1.HASPACE), but it could be changed. IMHO, easily changed. However I don't believe it really will be done. No business case. To comment original message: In case of SMS requirement of spool, VTOC change will not be the biggest issue. Even whole volume reformat. -- 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: Non-SMP/e packaging
On Sep 12, 2006, at 9:50 AM, Tom Marchant wrote: On Tue, 12 Sep 2006 09:02:23 -0500, Ed Gould [EMAIL PROTECTED] wrote: I would suggest that you decline the request and say that since CA-1 interacts and is IBM module dependent it is in the best interest of all parties to be in a deliverable state which facilitates IBM maintenance. SIGH/ They don't play nicely with others. So you are right, but there are other who do. I was not saying CA is good or bad and I was not making my comments saying one vendor is good or bad. There are vendors who do play by the rules some don't. Some who do not need to know what maintenance level is. A program that opens a file processes records probably does not need to know the PTF level of MVS. (there are some exceptions but I won't point fingers at this time). Programs that are dependent on mvs PTF level are IMO a must for smpe packaging. I know of one vendor that is extremely dependent on JES2 maintenance levels. I honestly don't remember if they SMPe packaged or not but I have read a bucket from the vendor and they talk about IBM PTF numbers. I do remember that they expect *YOU* (or your company) to be on almost bleeding edge JES2 maintenance. Ed It has been a long time since I did anything with CA-1, but I don't remember it ever having IFREQs on IBM maintenance, or even going into the same zone or belonging to Z038. Unless I am mistaken, Ed's comment doesn't apply. All it takes to nullify the advantages of an SMP/E installation is *one* request from the vendor to apply service with BYPASS(ID). That said, my preference has generally been for an SMP/E install, provided that it is done correctly. This is no trivial matter, and as Mark pointed out. Innovation does a fine job without it. I wouldn't ask them to divert resources from product development to provide proper SMP/E packaging. Tom Marchant -- 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: JCL
On 12 Sep 2006 13:14:44 -0700, [EMAIL PROTECTED] (Dave Salt) wrote: //DOW EXEC PGM=IKJEFT1A, // PARM='DOW' //SYSEXEC DD DISP=SHR,DSN=D44201.REXX.LIB(DOW) ZHBDOW DOW - STEP WAS EXECUTED - COND CODE 0012 You have PARM='DOW' specified on line 2 above, and REXX.LIB(DOW) specified on the SYSEXEC. Either remove the parm or remove the member name; you need one or the other, but not both. Thanks. I haven't used that utility before and didn't know how that parm worked. This job will be saved. -- 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: JCL
//DOW EXEC PGM=IKJEFT1A, // PARM='DOW' //SYSEXEC DD DISP=SHR,DSN=D44201.REXX.LIB(DOW) Thanks. I haven't used that utility before and didn't know how that parm worked. Actually, PGM=IRXJCL would probably be a better choice for running REXX execs. IKJEFT1A and IKJEFT1B are simply alternates for the terminal monitor program IKJEFT01 which can be used to execute TSO/E commands in batch jobs. Steve Runtsch ** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ** -- 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: Question : VTOC size - JES2 Volume
The latter keeps everything on cylinder boundaries. No longer relevent with ECKD and define extent! But, who cares if you lopp off a cylinder on a 3390-3 (or larger) sized dataset? 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: JCL
On Tue, 2006-09-12 at 15:58 -0500, Steve Runtsch wrote: Actually, PGM=IRXJCL would probably be a better choice for running REXX execs. Except for the fact that there is a lot of useful function available in the TSO environment. IKJEFT1A and IKJEFT1B are simply alternates for the terminal monitor program IKJEFT01 Not sure about 1A, but IKJEFT1B yields useful step completion codes (that IKJEFT01 does not). -- 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: Question : VTOC size - JES2 Volume
Ha! I'd like to see you try to catalog SYS1.HASPACE DEFINE NONVSAM ... VOL(SPL001 SPL002 SPL003 ...) As long as it's 59 volumes or less. That is one magic number I have never understood! 59? What power of two is that? 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: JCL
//SYSEXEC DD DISP=SHR,DSN=D44201.REXX.LIB(DOW) You shouldn't specify a member name for SYSEXEC 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
Access to FTP
We recently found out (or rather our auditers found out) that you don't need a TSO segment to use FTP from a PC to z/OS. I tested with an id that was only defined to one CICS region. I could not sign on to TSO with it. But, I could access FTP. Our security and audit people think this is a security exposure. Two questions: 1. Is it? 2. If it is, how do we close it? 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: Non-SMP/e packaging
My choice would be to stick with SMP/E and not waste the time to create something else. I am not sure what is considered so difficult about SMP (from a customer perspective, I have never been a packager). The only time I find it difficult is when you stick something like Omegamons CICAT in front of it. Those tools to simplify the install only seem to make it harder and take much longer (unless you go with blind faith or do it frequently enough to remember the idiosyncrasies). If there are customization steps in addition to SMP just spell them out and let me do the customization. Now, of course in some cases a full replacement process may be fast and easy but its more annoying and time consuming to have to know the peculiarities each vendor can come up with for installing/supporting their product(s). If the product is that simple, the SMP install should also be simple (again, I don't know what the packager has to go through to get it ready for me but defining a few SMP data sets then running receive/apply/accept from then on really isn't that big a deal). Remember, you asked for opinions and just about everyone has one :) Greg -- 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: Access to FTP
Having your host connected to a network is a security exposure. FTP on a *non* z/os host is a grave risk, and should be disabled. Auditors that don't understand the difference are also risks. FTP in and of itself does not grant access to data. It does facilitate access to data with a UACC other than NONE. To my thinking, *that* is the exposure, not FTP, TSO, or any other kind of host access. I personally like the RESTRICTED attribute. There, access has to be explicitly granted to each resource. UACC doesn't apply. I use that for several such situations. It is a little tricky to discover *all* of the needed resources. HTH and good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, September 12, 2006 4:23 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Access to FTP We recently found out (or rather our auditers found out) that you don't need a TSO segment to use FTP from a PC to z/OS. I tested with an id that was only defined to one CICS region. I could not sign on to TSO with it. But, I could access FTP. Our security and audit people think this is a security exposure. Two questions: 1. Is it? 2. If it is, how do we close it? When in doubt. PANIC!! 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: Access to FTP
On Tuesday, 09/12/2006 at 04:53 EST, Hal Merritt [EMAIL PROTECTED] wrote: Having your host connected to a network is a security exposure. FTP on a *non* z/os host is a grave risk, and should be disabled. Auditors that don't understand the difference are also risks. Huh? Disabling FTP is just one option. Using secure FTP is another. Alan Altmark z/VM Development IBM Endicott -- 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: Access to FTP
FTP on a *non* z/os host is a grave risk, and should be disabled. Do you mean FTP client or FTP server? FTP server on a non-z/OS host is often very useful. As for everything else, security needs to be considered. Disabling FTP client on desktop PCs is of little benefit as users can download numerous FTP clients at will. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Hal Merritt Sent: Tuesday, September 12, 2006 2:53 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Access to FTP Having your host connected to a network is a security exposure. FTP on a *non* z/os host is a grave risk, and should be disabled. Auditors that don't understand the difference are also risks. -- 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: Access to FTP
Having your host connected to a network is a security exposure. FTP on a *non* z/os host is a grave risk, and should be disabled. Auditors that don't understand the difference are also risks. Huh? Disabling FTP is just one option. Using secure FTP is another. I have obviously not made my point clear. The users using FTP are on our side of the firewall! They are FTP'ng from our z/OS system to our PC's. The distinction is our audit types think it should only be accessible from TSO ids. CICS ids (no TSO segment) work as well. This is internal to internal machine transfer. Is this a security exposure? I don't think so. 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: Non-SMP/e packaging
Binyamin Dissen wrote: I don't think you can qualify as a true system programmer unless you (1) do something that causes the system to loop/crash and (2) you use the manual screen to fix memory so that an IPL is not needed How about entering stuff from the front panel and causing a machine check? G Gerhard Postpischil Bradford, VT -- 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: JCL
On Sep 12, 2006, at 3:58 PM, Steve Runtsch wrote: ---SNIP--- Actually, PGM=IRXJCL would probably be a better choice for running REXX execs. IKJEFT1A and IKJEFT1B are simply alternates for the terminal monitor program IKJEFT01 which can be used to execute TSO/E commands in batch jobs. Steve Runtsch Steve, IIRC 1A gives a return code, 01, IIRC does not. I am not sure about 1B. 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: Format 2 save area?
Ray Mullins wrote: I was researching an abend in Unicode translation services code that I brought upon myself (bad length passed), and have since fixed. However, I ran into something interesting that I could not find any explanatory doc. I was looking at R13 in the RTM2WA and voila - I see F2SA in save area + 4. So off to the bookshelves and I can find references to F4SA, F5SA, F6SA, F7SA, as well as the old reliable F1SA. But no F2SA (or F3SA if that matters). I'll bet it's a typo. Probably intended to be F1SA. Might even be APARable. In the dump, was the linkage stack used as one would expect with F1SA? I've searched IBM-MAIN and ASSEMBLER-LIST archives. I've found some descriptions of F4 and F5, but not F2. I've also searched the IBM libraries (to z/OS 1.8), as well as SYS1.MACLIB and MODGEN but I have not been rewarded for my endeavours. Has anyone ran into this before? Peter Relson, any comments? (I found your great detailed explanations of F4 and F5 from 4 years ago.) AFAIK, all of the valid save area formats are described in SYS1.MACLIB(IHASAVER). Format-0 and Format-1 both use the original 'SAVER' format. The only difference is that Format-1 sets SAVPREV to 'F1SA' instead of containing an address. -- 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: Question : VTOC size - JES2 Volume
Ted MacNEIL wrote: That is one magic number I have never understood! 59? What power of two is that? Three extents described by the F1 DSCB plus fourteen extents described by each F3 DSCB up to a max of four F3 DSCBs. -- 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: Access to FTP
You might have the FACILITY class profile BPX.DEFAULT.USER setup at your site allowing anyone with a valid RACF userid access. See z/OS UNIX System Services Planning. If not users who lacked an OMVS segment would probably not be able to use FTP. It is fairly considered a facility worthy of attention by some sites. Some sites like ours and probably yours tightly controlled access to IND$FILE on the premise that providing channel outside the glass walls it needed careful control. In fairness the glass walls have a lot of little hamster tubes running in and out today:-) So no one can say for your site if it is a security exposure or not but your management and auditors might reasonably ask your help in securing it just like TSO nee TSO IND$FILE. If your RACF data set profiles and userids are not properly setup and audited it might be providing unintended access. The argument for it being a problem is that the CICS users generally don't have access to data sets not having TSO and ISPF but only limited transactions to use. With FTP any userid can be used as a means to directly access MVS or USS data sets and data sets with UACC of READ or higher might not be something you ever intended to make available. You could use the FTCHKPWD exit can be used to lock FTP down using just about any way you want. See the sample in TCPIP.SEZAINST(FTCHKPWD). Just be careful whatever you do you don't pull the rug out from under users who consider their use of FTP part of their job. You might start with reviewing SMF data to see what access is actually being done today. Good luck and have fun! Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Tuesday, September 12, 2006 5:23 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Access to FTP We recently found out (or rather our auditers found out) that you don't need a TSO segment to use FTP from a PC to z/OS. I tested with an id that was only defined to one CICS region. I could not sign on to TSO with it. But, I could access FTP. Our security and audit people think this is a security exposure. Two questions: 1. Is it? 2. If it is, how do we close it? 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
Re: Non-SMP/e packaging
I once installed a product called TASA from INFOSECINC. The package is downloadable from the company's web site as a binary file. It then is TSO RECEIVED into a samplib. The supplied install jobs do all the SMPE stuff. Seems the best of both worlds. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Tuesday, September 12, 2006 11:03 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Non-SMP/e packaging Mark Zelden wrote: [...] A perfect example is Innovation's FDR. I have used it in virtually I have never heard complaints about FDR support, etc. Is seems that SMP/E is not crucial to it. People discuss about *binary* alternatives: SMP/E or library unload. I think there are other ways to manage the code. Even SMP/E could be simpler. Current conceptions are for historical reasons, not because of real needs. Compromise between history and usability makes SMP/E difficult to understand and then cumbersome. Why don't we think about SMP2 - new approach, totally free of old junk. 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 -- 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: Access to FTP
On 12 Sep 2006 16:07:17 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (Ted MacNEIL) wrote: The users using FTP are on our side of the firewall! They are FTP'ng from our z/OS system to our PC's. The distinction is our audit types think it should only be accessible from TSO ids. CICS ids (no TSO segment) work as well. You need a TSO id to use TSO. You don't need one to use CICS, or run batch jobs, because they're not TSO. I'd ask the auditors what connection they think there is between FTP and TSO. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot 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: Access to FTP
I'd ask the auditors what connection they think there is between FTP and TSO That was the question I started with, here. 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: SHARE attendance
Ed Gould wrote: Anyone have the number for attendance of SHARE in Baltimore? Someone emailed me offline and said it was low. Can anyone confirm/ clarify the numbers? Ed One of the chairs said that it was less than 2,000. -- 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: Access to FTP
In [EMAIL PROTECTED], on 09/12/2006 at 09:23 PM, Ted MacNEIL [EMAIL PROTECTED] said: We recently found out (or rather our auditers found out) that you don't need a TSO segment to use FTP from a PC to z/OS. Water is wet. Our security and audit people think this is a security exposure. ROTF,LMAO! 1. Is it? No. But while they're chasing an imaginary exposure there may be real exposures that they're unaware of. -- 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: Another BIG Mainframe Bites the Dust
In [EMAIL PROTECTED], on 09/11/2006 at 03:59 PM, Clark F Morris [EMAIL PROTECTED] said: I remember the 301, 3301 and 501. What was the 601? 24-bit instructions in 48-bit (plus parity and tags) word. Multilevel indexing and indirect addressing. -- 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
