Will there be HOLDDATA for ACCEPTED sysmods was Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On 13 Aug 2006 15:51:35 -0700, in bit.listserv.ibm-main you wrote: At 01:57 -0400 on 08/12/2006, Arthur T. wrote about Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ): On 11 Aug 2006 21:02:35 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (Robert A. Rosenberg) wrote: If I do the RESTORE the current way and back off 10 SYSMODS only to do the APPLY and apply 9 of them, why is this safer/more correct than just doing a forward APPLY of those element(s) of the backed-off SYSMOD that were taken from the other 9 SYSMODs during the Apply step that was done after the Restore? I've cursed SMP for the same reasons. However, I can think of reasons that the current method is safer or more correct: 1. If you've Received Holddata between the Apply and Restore, it may be that one of those other Sysmods is PEd, SUPed, or some such. See my reply to point 3 below. I do not think that it is hard to do a scan to see if Holddata issued AFTER the date of the APPLY would have blocked the APPLY (I think that the date of the APPLY is stored in the element's entry as well as each HOLDDATA entry having a similar issued date). Will the HOLDDATA even be loaded for something which has been ACCEPTED? If so will the SYSMOD be shown in an error report. At one time, I was told that HOLDS for Accepted SYSMODS were effectively discarded. -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
Been There, Done That, Got The . . . Subsystem? Starship? Solid State? Schutzstaffeln? g Jon snip BTDTGTSS /snip Been There, Done That, Got T-Shirt Scars --- [This E-mail has been scanned for viruses by the YourNet Connection Virus system] [For more information, please go to http://www.ync.net/YourMAIL] -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
At 01:57 -0400 on 08/12/2006, Arthur T. wrote about Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ): On 11 Aug 2006 21:02:35 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (Robert A. Rosenberg) wrote: If I do the RESTORE the current way and back off 10 SYSMODS only to do the APPLY and apply 9 of them, why is this safer/more correct than just doing a forward APPLY of those element(s) of the backed-off SYSMOD that were taken from the other 9 SYSMODs during the Apply step that was done after the Restore? I've cursed SMP for the same reasons. However, I can think of reasons that the current method is safer or more correct: 1. If you've Received Holddata between the Apply and Restore, it may be that one of those other Sysmods is PEd, SUPed, or some such. See my reply to point 3 below. I do not think that it is hard to do a scan to see if Holddata issued AFTER the date of the APPLY would have blocked the APPLY (I think that the date of the APPLY is stored in the element's entry as well as each HOLDDATA entry having a similar issued date). 2. If any of the 10 had JCLIN, things could get tricky. Especially tricky if the one you're Restoring had JCLIN. ONLY if the To-be-Restored SYSMOD has JCLIN (or is PRE'ed by another SYSMOD with JCLIN). Note that my method automatically merges an SYSMODs that PRE the named SYSMODs and treats them as if they were listed in the SELECT clause. So long as the SYSMODs to be backed off have no JCLIN, there is no problem since any LMODs get created the same (just possibly with earlier versions of the backed off elements). 3. SMP won't know if you did any BYPASSes when Applying. If you had, things could get tricky. Better that a person do trickiness than trusting it to SMP. I am only addressing what I perceive as a basic design flaw in the original implementation. To avoid the potential problems you list, I'd agree to a RESTORE CHECK option - ie: Do the Restore as a Check followed by an under-the-covers APPLY CHECK suppressing the SELECTED SYSMODs to see if the result is the same as just backing off the relevant elements. The result is a report that says either that just Forward APPLY'ing (ie: Doing an APPLY only with prior versions of the elements in the SYSMODs) will result in the same state as the current RESTORE/APPLY process would or that one or more SYSMODs will not go on (probably due to newer HOLDS) and list the reasons (similar to the current APPLY CHECK BYPASS report). Also, IBM has limited resources for SMP enhancements. I suspect it would be easier to code SMP to Restore all 10, then automatically re-Apply the other 9. (Or, at least, automatically create the control cards for doing so.) -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On 11 Aug 2006 21:02:35 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (Robert A. Rosenberg) wrote: If I do the RESTORE the current way and back off 10 SYSMODS only to do the APPLY and apply 9 of them, why is this safer/more correct than just doing a forward APPLY of those element(s) of the backed-off SYSMOD that were taken from the other 9 SYSMODs during the Apply step that was done after the Restore? I've cursed SMP for the same reasons. However, I can think of reasons that the current method is safer or more correct: 1. If you've Received Holddata between the Apply and Restore, it may be that one of those other Sysmods is PEd, SUPed, or some such. 2. If any of the 10 had JCLIN, things could get tricky. Especially tricky if the one you're Restoring had JCLIN. 3. SMP won't know if you did any BYPASSes when Applying. If you had, things could get tricky. Better that a person do trickiness than trusting it to SMP. Also, IBM has limited resources for SMP enhancements. I suspect it would be easier to code SMP to Restore all 10, then automatically re-Apply the other 9. (Or, at least, automatically create the control cards for doing so.) -- 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: SMPE packaging was Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin [ snip ] Flexibility is not always a virtue: did you ever try to sit on a very flexible chair? (Heard from Bill Waite; origin uncertain) Indeed. Instead of a tightrope, erect a bungee -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
---snip- That is until you have to RESTORE a SYSMOD at while point SMP/E causes you to do lots of useless work. The intent of a RESTORE is to create a system as if that SYSMOD (and possibly SYSMODs that PRE it) had not yet been APPLYed. The CORRECT way of doing a RESTORE operation is to determine which elements must be backed off and which SYSMODs contain the replacement versions of the elements. The current implementation causes you to have to remove (and subsequently reAPPLY) SYSMODS that have nothing to do with the one being RESTOREd. As a simple example, SYSMOD1 contains elements A, B, and C while SYSMOD2 contains only element B and PREs SYSMOD1. Both are currently in APPLY status. To RESTORE SYSMOD2, I must also RESTORE SYSMOD1 (and possibly SYSMOD3 which PREs SYSMOD1 since it contains a newer copy of A and/or C but not B). All that is needed is to just reAPPLY element B from SYSMOD1 and you have RESTOREd SYSMOD2 but SMP/E goes through useless work to back off A and C also (along with other elements in SYSMODs on the PRE chain that is anchored at SYSMOD1) only to then do an APPLY (sans SYSMOD2) of all the erroneously RESTOREd SYSMODs. If all you want to do is RESTORE B, you should run the element SUP chain on B until you find a copy to APPLY/use (in this case the copy in SYSMOD1) and ignore everything else. RESTORE is a flawed design since it involves elements that are not affected when the correct versions are available from SYSMODs still in APPLY status or from the DLIB copy of the element. unsnip NEVER assume SYSMODS are unrelated. Control block changes and dependancies can cause changes in things that appear to be completely unrelated, but mis-matches in code in CSECTS/RSECTS that use those blocks can have DISASTROUS consequences. BTDTGTSS Learned the hard way trying to install 3490E drives without pre-req maintenance and the drives kept coming up as a strange flavor of disk drive! Many interdependancies can, and do, span component boundaries and thus appear completely unrelated. --- [This E-mail has been scanned for viruses by the YourNet Connection Virus system] [For more information, please go to http://www.ync.net/YourMAIL] -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
Been There, Done That, Got The . . . Subsystem? Starship? Solid State? Schutzstaffeln? g Jon snip BTDTGTSS /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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
At 10:36 -0500 on 08/11/2006, Rick Fochtman wrote about Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ): ---snip- That is until you have to RESTORE a SYSMOD at while point SMP/E causes you to do lots of useless work. The intent of a RESTORE is to create a system as if that SYSMOD (and possibly SYSMODs that PRE it) had not yet been APPLYed. The CORRECT way of doing a RESTORE operation is to determine which elements must be backed off and which SYSMODs contain the replacement versions of the elements. The current implementation causes you to have to remove (and subsequently reAPPLY) SYSMODS that have nothing to do with the one being RESTOREd. As a simple example, SYSMOD1 contains elements A, B, and C while SYSMOD2 contains only element B and PREs SYSMOD1. Both are currently in APPLY status. To RESTORE SYSMOD2, I must also RESTORE SYSMOD1 (and possibly SYSMOD3 which PREs SYSMOD1 since it contains a newer copy of A and/or C but not B). All that is needed is to just reAPPLY element B from SYSMOD1 and you have RESTOREd SYSMOD2 but SMP/E goes through useless work to back off A and C also (along with other elements in SYSMODs on the PRE chain that is anchored at SYSMOD1) only to then do an APPLY (sans SYSMOD2) of all the erroneously RESTOREd SYSMODs. If all you want to do is RESTORE B, you should run the element SUP chain on B until you find a copy to APPLY/use (in this case the copy in SYSMOD1) and ignore everything else. RESTORE is a flawed design since it involves elements that are not affected when the correct versions are available from SYSMODs still in APPLY status or from the DLIB copy of the element. unsnip NEVER assume SYSMODS are unrelated. Control block changes and dependancies can cause changes in things that appear to be completely unrelated, but mis-matches in code in CSECTS/RSECTS that use those blocks can have DISASTROUS consequences. I am NOT assuming that SYSMODs are unrelated. I am just following the PRE/SUP indications in the SYSMOD Statements as supplied. If I do the RESTORE the current way and back off 10 SYSMODS only to do the APPLY and apply 9 of them, why is this safer/more correct than just doing a forward APPLY of those element(s) of the backed-off SYSMOD that were taken from the other 9 SYSMODs during the Apply step that was done after the Restore? Note what my Correct RESTORE does - It asks what SYSMOD supplied the element(s) that is/are being replaced by the to-be-RESTOREd SYSMOD and says to back off the element(s) by using those from the PREd/SUPd SYSMOD WITHOUT affecting any Element that is not in the SYSMOD (or one that PREs it). If you can not follow what I said in the quote above, I will list a string of SYSMODs (with elements) and show how my method follows the packaging rules yet is more efficient than the RESTORE-and-APPLY method currently forced by a poor design of the RESTORE function. -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
At 14:38 -0500 on 08/10/2006, Tom Marchant wrote about Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ): On Wed, 9 Aug 2006 23:09:16 -0400, Robert A. Rosenberg [EMAIL PROTECTED] wrote: At 18:08 -0500 on 08/09/2006, Tom Marchant wrote about Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ): I can assure you that many vendors produce inferior SMP/E. SMP/E is a powerful tool, and when the SYSMODs are coded correctly, it makes installing and maintaining a system easy. That is until you have to RESTORE a SYSMOD at while point SMP/E causes you to do lots of useless work. The intent of a RESTORE is to create a system as if that SYSMOD (and possibly SYSMODs that PRE it) had not yet been APPLYed. The CORRECT way of doing a RESTORE operation is to determine which elements must be backed off and which SYSMODs contain the replacement versions of the elements. The current implementation causes you to have to remove (and subsequently reAPPLY) SYSMODS that have nothing to do with the one being RESTOREd. As a simple example, SYSMOD1 contains elements A, B, and C while SYSMOD2 contains only element B and PREs SYSMOD1. Both are currently in APPLY status. To RESTORE SYSMOD2, I must also RESTORE SYSMOD1 (and possibly SYSMOD3 which PREs SYSMOD1 since it contains a newer copy of A and/or C but not B). All that is needed is to just reAPPLY element B from SYSMOD1 and you have RESTOREd SYSMOD2 but SMP/E goes through useless work to back off A and C also (along with other elements in SYSMODs on the PRE chain that is anchored at SYSMOD1) only to then do an APPLY (sans SYSMOD2) of all the erroneously RESTOREd SYSMODs. If all you want to do is RESTORE B, you should run the element SUP chain There is no such thing as an element SUP chain. OK - Poor nomenclature. What I was getting at is that when I do an APPLY, I am superseding the RMID ownership of the element and assigning that of the new SYSMOD. Thus I have SUP'ed the old copy of the Element and supplied a new copy. on B until you find a copy to APPLY/use (in this case the copy in SYSMOD1) and ignore everything else. RESTORE is a flawed design since it involves elements that are not affected when the correct versions are available from SYSMODs still in APPLY status or from the DLIB copy of the element. Elements from the sysmod being restored *always* come from the DLIB zone. Why should they when there is a newer valid copy available in another SYSMOD in APPLY Status? You and I can disagree about the design of RESTORE. I don't have a problem with the way it works. I've heard arguments similar to your many times, but I have seldom had a problem with it. Prior to a RESTORE, it is sometimes necessary to ACCEPT service up to the one(s) that I want to restore. While that this can be a nuisance with a product that has had many ++ZAPs applied to a module, most of the time it is not such a big deal. Tom Marchant Can you justify the forced need to do unnecessary work just to back off a SYSMOD. To make it simple, here is a scenerio: The initial state of the Target Zone is no SYSMODs in APPLY status. I now do an APPLY step that APPLYs 10 SYSMODs that are inter-related in that after I am done, there is at least one element that was updated that came from each of the 10 SYSMODs. Now I want to RESTORE one of the SYSMODs and all of the elements that are contained in it currently have its RMID as their owner (IOW: The SYSMOD is not SUPed or PREd and we could have successfully done the APPLY of only 9 of the SYSMODs by omitting it). With the current Brain-Dead design of RESTORE I am forced to remove ALL 10 of the SYSMODs and then reAPPLY 9 of them just to back off the 10th instead of just taking its elements from whichever of the remaining 9 SYSMODs had the latest version (or if none had a copy, using the copy from the DLIB). Please explain why the current methodology is better than just identifying which SYSMODs would have supplied those elements in the to-be-RESTOREd SYSMODs if it had never been APPLYed and just reAPPLYing them (along with those extra elements that were in those SYSMODs that PRE the to-be-RESTOREd SYSMODs [ie: Those that APPLYed only because the to-be-RESTOREd SYSMODs were either simultaneously being APPLYed or were already in APPLY status]). NOTE: I am assuming that no BYPASS(ID) magic was done to force the APPLY to work in violation of the PRE/SUP Chain. -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
SNIPPETS -I- am not telling you anything of the sort. I am telling you that customers who write big checks for enterprise software products have made enough fuss about this issue that pretty much all of the vendors provide gooberware to assist with installation and configuration of their software. You can choose to believe me or not, I won't lose any sleep either way. END of SNIPPETS When I saw the divergence of autoinstallers and SMP/e in a product, I went the SMP/e way for the reason that it kept my methods in line for products and system stuff. I've been exposed to autoinstallers in both VM and MVS worlds and never had a particular fondness for them. Things get stuck into mysterious places and customization routines which ask for inputs seem to have their share of troubles. Now thinking back to the days of SMP IV and superzap...I like the newer SMP/e. My concession to the 'GUI' SMP/e panels is that I like to create the commands and store off the resulting jobstreams both for example and for documentation. I am NOT looking for Big Blue or any other vendor to come out with the patch-mania that drives certain desktop systems. Daniel McLaughlin ZOS Systems Programmer Crawford Company PH: 770 621 3256 * Victory is won not in miles but in inches. Win a little now, hold your ground, and later, win a little more. ? Louis L'Amour -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
Chris, I have made issues to management about the installability and maintainability of vendor products. I have also told management that they should turn down a product because of these issues. More than a few times management followed my recommendations. I do not want to get into a vendor X or vendor Y specifics (unless you want me to). I also have installed a fair number of vendor products (probably over 200) . As you would expect some lead you by the nose in every step while some take a laid back. Yes there are vendors that are good and likewise poor (or terrible) (installability). Cookbook approaches can be best used when it is a simple install (ie link edit one or two modules) when it gets to many more modules it can get complicated or reasonably straight forward. I changed the parm of the linkage editor (added size=(999K,400K) IIRC) and the vendor refused to talk to me unless I deinstalled it and used the parms EXACTLY what was in the canned JCL. Like I said some vendors don't have a clue. The best suggestion I can say is that you must use the install experience when it comes time to decide if you want to buy product X. 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Wednesday, August 09, 2006 10:49 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ) snip It is all very well to say you don't like assistance from the autocurse software snip I think maybe I should clarify something. I mentioned that Autocust was known internally as autocurst (formerly a Boole Babbage product customizer for two product lines). I did not intend to imply that any pre/post SMP/E customization provided by any vendor was a detestable thing. The reason that we referred to it as autocurst was you were cursed if you had to work on it. This was because it was a mixture of CLIST, REXX, ISPF tables, panels, some programs, etc. When you made changes to it you had to recognize the level of the OS you were under, the level of ISPF (and if PDF was available), which level of TSO/E you were running under, the level of JES, etc. And it was so easy to break the whole thing (and there were a few people who managed to do this enough that no one wanted them to touch it again). Finally, one person (I honestly can't recall his name, but he got transferred to Empact (Stop X37 folks)) sat down and overhauled the whole thing, getting rid of obsolete code, poor coding constructions etc. On the other hand, if you got interrupted while doing the install, it could remember the last thing you had completed and upon re-entering autocust it would take you to the panel for the next thing you needed to do (and it might grind for about 5 minutes to do it). And it tended to be used by customers to help them customize their next install as it remembered most all of their site customization data. But it was a royal pain to have to change to fix something or add a new function/feature or option. 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
SMPE packaging was Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On 9 Aug 2006 20:49:25 -0700, in bit.listserv.ibm-main you wrote: I guess that means that you think they can't install MVS. In all the years I've been in this business, people have been telling me that this group or that is full if idiots. People who were incapable of learning, or worse, that anything that they might learn will only make them screw things up worse. A little knowledge is a dangerous thing. I call it the user- dummy syndrome. I have variously been told that users, programmers, operators, analysts, vendors, managers and customers are dummys. -I- am not telling you anything of the sort. I am telling you that customers who write big checks for enterprise software products have made enough fuss about this issue that pretty much all of the vendors provide gooberware to assist with installation and configuration of their software. You can choose to believe me or not, I won't lose any sleep either way. Here I agree with the management that wants something simpler than SMP/E for installation. I also believe that the overall design needs a revisit given the following: 1. A RESTORE can be painful if it involves more than one SYSMOD or a chain. I don't know if I ever did a restore, finding it simpler to go back to a previous system or to move forward. 2. SMP may still not cover all of the entities (I'm not certain if the printer FCBs were covered for example) and still may not support such things as panel compilation or prepping. 3. The reporting, while probably improved still may need further work for things such as system HOLDS, where grouping like reasons would reduce the amount of review. 4. The dependency maintenance must be difficult to keep straight and any aids for this would be of use for all vendors. 5. We may also need to react faster to security fixes as the platform is used more and more for Internet business. 6. Having a common install process for all system related software that both allows each vendor's code to be kept separate but also checks for interdependencies would be extremely useful. Note this is also needed for DB2, IMS and CICS. 7. If the philosophy in Websphere Developer could be adapted this might allow applications people to be moved into systems easier. Not knowing enough about the product, I can't judge whether this would be disastrous. 8. SMP should be able to control and run source modifications for any language supported by the z series. This includes COBOL. After all JARS (SMF reporting) was written in COBOL. If IBM would implement the requirement to implement the bit and native binary data type in the 2000 standard COBOL could work with any IBM defined data area. Reference modification already makes it simple to rearrange the SMF type 30 record. It will be fun getting to a new or even noticeably improved system and the definition of what new and improved should look like and do will not be easy. However if it makes it easier to package code, install same, update it and modify it with greater safety it will be well worth the aggravation. I can assure you that many vendors produce inferior SMP/E. SMP/E is a powerful tool, and when the SYSMODs are coded correctly, it makes installing and maintaining a system easy. When PTFs are sent without the REQs coded properly and the vendor tells me to BYPASS ID, I have to wonder why they bother with SMP at all. So you say. On the other hand, you could apply the same reasoning to vendor employees that you did to your own peers. They are just trying to do the best job they can for their customers. That's not all good or all bad. It just is the way it is. Installation aids may NOT be to your taste perhaps, but the vendors aren't providing them to p*ss you off and they're not all incompetent. Ask yourself why the vendors would bother doing all that extra junk if their customers weren't asking for it? It is all very well to say you don't like assistance from the autocurse software. Fine. I could care less. What I am really annoyed about is this constant blather that (all) vendors don't have a clue what they're doing. Perhaps you could do better, but I wouldn't bet a paycheck on it. Given the cost and complexity of producing this sort of thing, I believe the idea is good, the customer need is there but that it should be a multi-vendor effort (possibly an open source style operation like Linux or CVS). CC -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Wed, 9 Aug 2006 23:09:16 -0400, Robert A. Rosenberg [EMAIL PROTECTED] wrote: At 18:08 -0500 on 08/09/2006, Tom Marchant wrote about Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ): I can assure you that many vendors produce inferior SMP/E. SMP/E is a powerful tool, and when the SYSMODs are coded correctly, it makes installing and maintaining a system easy. That is until you have to RESTORE a SYSMOD at while point SMP/E causes you to do lots of useless work. The intent of a RESTORE is to create a system as if that SYSMOD (and possibly SYSMODs that PRE it) had not yet been APPLYed. The CORRECT way of doing a RESTORE operation is to determine which elements must be backed off and which SYSMODs contain the replacement versions of the elements. The current implementation causes you to have to remove (and subsequently reAPPLY) SYSMODS that have nothing to do with the one being RESTOREd. As a simple example, SYSMOD1 contains elements A, B, and C while SYSMOD2 contains only element B and PREs SYSMOD1. Both are currently in APPLY status. To RESTORE SYSMOD2, I must also RESTORE SYSMOD1 (and possibly SYSMOD3 which PREs SYSMOD1 since it contains a newer copy of A and/or C but not B). All that is needed is to just reAPPLY element B from SYSMOD1 and you have RESTOREd SYSMOD2 but SMP/E goes through useless work to back off A and C also (along with other elements in SYSMODs on the PRE chain that is anchored at SYSMOD1) only to then do an APPLY (sans SYSMOD2) of all the erroneously RESTOREd SYSMODs. If all you want to do is RESTORE B, you should run the element SUP chain There is no such thing as an element SUP chain. on B until you find a copy to APPLY/use (in this case the copy in SYSMOD1) and ignore everything else. RESTORE is a flawed design since it involves elements that are not affected when the correct versions are available from SYSMODs still in APPLY status or from the DLIB copy of the element. Elements from the sysmod being restored *always* come from the DLIB zone. You and I can disagree about the design of RESTORE. I don't have a problem with the way it works. I've heard arguments similar to your many times, but I have seldom had a problem with it. Prior to a RESTORE, it is sometimes necessary to ACCEPT service up to the one(s) that I want to restore. While that this can be a nuisance with a product that has had many ++ZAPs applied to a module, most of the time it is not such a big deal. 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Wed, 9 Aug 2006 23:49:07 -0400, Craddock, Chris [EMAIL PROTECTED] wrote: ... So you say. On the other hand, you could apply the same reasoning to vendor employees that you did to your own peers. They are just trying to do the best job they can for their customers. That's not all good or all bad. It just is the way it is. Installation aids may NOT be to your taste perhaps, but the vendors aren't providing them to p*ss you off and they're not all incompetent. Ask yourself why the vendors would bother doing all that extra junk if their customers weren't asking for it? It is all very well to say you don't like assistance from the autocurse software. Fine. I could care less. What I am really annoyed about is this constant blather that (all) vendors don't have a clue what they're doing. Perhaps you could do better, but I wouldn't bet a paycheck on it. ... Not surprising, vendors see clueless customers and customers see clueless vendors. There are more customers than vendors in the world and I suspect the percentage of Bozos is higher among customers than vendors. But the Bozos exist on both sides. From what I've seen (and it's all been from the customer side) the quality of a product and the quality of the packaging of that product have little to do with each other, and that's the case whether or not SMP is involved. Good packaging (with or without SMP) lets the product be easily installed in customer environments not envisioned by the vendor. We tend not to remember tools that permit that because there is (hopefully) nothing memorable about success. Bad packaging makes a non-standard installation a nightmare. The real autocurse tools and instructions (including some IBM Program Directories) are those that can't be adapted to the customer's environment. THOSE are memorable, and those we complain about. Chris, if you feel we are using too broad a brush in our complaints, well, you are probably right. Sorry. But if your packaging works well we probably aren't going to even notice it. The best you can hope for is a lack of complaints. And if both the packaging and the product are good you continue getting a paycheck. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMPE packaging was Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
In a recent note, Clark F Morris said: Date: Thu, 10 Aug 2006 13:03:52 -0300 Here I agree with the management that wants something simpler than SMP/E for installation. I also believe that the overall design needs a revisit given the following: 1. A RESTORE can be painful if it involves more than one SYSMOD or a chain. I don't know if I ever did a restore, finding it simpler to go back to a previous system or to move forward. Agreed. A model to study here is VM/CMS/VMFMERGE. VMFMERGE is entirely devoid of (an analog of) the ACCEPT command. Rather, its (analog of) the RESTORE command retrieves all elements from (the analog of) the SMPPTS. If a redesigned SMP/E did likewise, ACCEPT would be optional or unnecessary, and RESTORE could become an UNDO of an arbitrary number of layers, and even done iteratively if desired. 2. SMP may still not cover all of the entities (I'm not certain if the printer FCBs were covered for example) and still may not support such things as panel compilation or prepping. Agreed. The repertoire of utilities should not be a fixed handful, but extensible without limit by the user or ISV. This would require considerable extension of SMP/E's analysis of JCLIN in order properly associate libraries in the JCL with DDDEFS in SMP/E. It would no longer be possible to rely on a fixed set of DDNAMEs such as SYSLIB and SYSLMOD. 3. The reporting, while probably improved still may need further work for things such as system HOLDS, where grouping like reasons would reduce the amount of review. And here, SMP/E outshines VMFMERGE. 4. The dependency maintenance must be difficult to keep straight and any aids for this would be of use for all vendors. No longer a concern for us since we have the process automated. But we stumbled repeatedly along the way, and would have appreciated an aid, even as SMP/E provides GIMZIP and GIMDTS to assist vendors in those packaging operations. This might take the form of an APPLY GENDEPEND operation, where the developer could supply to a fully populated and up-to-date target zone a partial SYSMOD, lacking PRE and SUP statements, and SMP/E could write to SMPRPT the suggested content of those statements. 6. Having a common install process for all system related software that both allows each vendor's code to be kept separate but also checks for interdependencies would be extremely useful. Note this is also needed for DB2, IMS and CICS. And might require unprecedented coordination among the vendors. 8. SMP should be able to control and run source modifications for any language supported by the z series. This includes COBOL. After all JARS (SMF reporting) was written in COBOL. If IBM would implement the requirement to implement the bit and native binary data type in the 2000 standard COBOL could work with any IBM defined data area. Reference modification already makes it simple to rearrange the SMF type 30 record. Somewhat similar to (2. extending the utility set), isn't it. It will be fun getting to a new or even noticeably improved system and the definition of what new and improved should look like and do will not be easy. However if it makes it easier to package code, install same, update it and modify it with greater safety it will be well worth the aggravation. Yes. And here, as previously, I take issue with the view that each site should set its own conventions for data set names. Taking the vendor knows best view facilitates interoperability of products from different vendors (example: we learned by unpleasant experience that many vendor products work poorly or not at all unless TCPIP is the HLQ for IBM's TCPIP product). Likewise, it facilitates transfer of skills and JCL from site to site. (Imagine if a site were to use a local prefix instead of SYS1. In this respect, IBM is merely the biggest vendor among many and the same considerations that govern IBM's names should apply to other vendors.) Likewise, using the vendors' data set names allows the vendor-supplied documentation to be used without an errata sheet to correct for local names. It has been suggested here, in refutation, that installing the documentation could include tailoring for local naming conventions. Perhaps SMP/E should provide support for such a tailoring utility in the extended utility set in bullet (2). I know, it could be done with HLASM AREAD and PUNCH statements, but would you really want to? Flexibility is not always a virtue: did you ever try to sit on a very flexible chair? (Heard from Bill Waite; origin uncertain) OTOH, and before others take issue, the vendor _should_ provide a facility for installation with alternative data set name(s) to allow construction of test systems. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED]
Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
In [EMAIL PROTECTED], on 08/08/2006 at 11:41 AM, Tom Marchant [EMAIL PROTECTED] said: I'd hope so too, but some vendors consistently do it wrong. Back in the 1980's the JES2 folks also did it consistently wrong. Now there's a statement that I think is a bit out there. How about rewording it to So there are lots of things that vendors have to take into consideration, and the biggest one today are the people calling themselves Sr. Systems Programmers who don't know what a USERMOD is or a JES exit. I'd like to say that Steve is exaggerating, but I've seen too many of the people he's referring to. -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
In [EMAIL PROTECTED], on 08/08/2006 at 08:25 PM, Clark F Morris [EMAIL PROTECTED] said: Could people comment on the other IBM maintenance methodologies, the ones for VM, VSE, AIX and OS400 and how they compare to SMP/E? I don't know how SESS-pool compares to SMP/E, but the CMS UPDATE facility use for VM source maintenance is head and shoulders above the IEBUPDTE used by SMP/E. And I speak as an admitted TSO bigot. SMP/E does a much better job of handling dependencies than the common tools in the PC and Unix worlds. -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Tue, 8 Aug 2006 18:41:27 -0400, Craddock, Chris [EMAIL PROTECTED] wrote: ... I can't speak for all vendors, but trust me the reason is NOT because the vendors don't know how to package SMP/E deliverables. There is (at least in the ones I have dealt with) a full SMP/E install under those covers. The autocurse installers exist because a significant number of customers ask (demand!) them. ... There are also vendors that don't provide SPM packaging until customers badgered have them into doing it; then produced junk that used SMP. It's usually pretty easy to tell which kind of a vendor you're dealing with. (And you probably don't find that latter kind on IBM-Main.) A serious side effect of this poor packaging is the sample it gives Jr System Programmers trying to learn SMP by on-the-job training. You would never see an advantage of SMP if all you see is examples of poor packaging. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Tue, 8 Aug 2006 18:41:27 -0400, Craddock, Chris [EMAIL PROTECTED] wrote: ... front ends to SMP/E, to cover up for the fact that the vendor doesn't have a clue how to create proper SYSMODs. Let alone HOLDDATA. I can't speak for all vendors, but trust me the reason is NOT because the vendors don't know how to package SMP/E deliverables. There is (at least in the ones I have dealt with) a full SMP/E install under those covers. The autocurse installers exist because a significant number of customers ask (demand!) them. The ibm-main audience is not necessarily typical because there are a lot of customers who can't spell SMP/E let alone configure high end software products. I guess that means that you think they can't install MVS. In all the years I've been in this business, people have been telling me that this group or that is full if idiots. People who were incapable of learning, or worse, that anything that they might learn will only make them screw things up worse. A little knowledge is a dangerous thing. I call it the user- dummy syndrome. I have variously been told that users, programmers, operators, analysts, vendors, managers and customers are dummys. I have found that the vast majority of the people in all of these categories are hard working prople who really want to do their job better. I have always tried to help all of these people to understand things better, and I have never regretted it. Many organizations suffer from a culture that makes improvement difficult, and it is often difficult people in any of these categories to see things from other perspectives. I can assure you that many vendors produce inferior SMP/E. SMP/E is a powerful tool, and when the SYSMODs are coded correctly, it makes installing and maintaining a system easy. When PTFs are sent without the REQs coded properly and the vendor tells me to BYPASS ID, I have to wonder why they bother with SMP at all. 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
I guess that means that you think they can't install MVS. In all the years I've been in this business, people have been telling me that this group or that is full if idiots. People who were incapable of learning, or worse, that anything that they might learn will only make them screw things up worse. A little knowledge is a dangerous thing. I call it the user- dummy syndrome. I have variously been told that users, programmers, operators, analysts, vendors, managers and customers are dummys. -I- am not telling you anything of the sort. I am telling you that customers who write big checks for enterprise software products have made enough fuss about this issue that pretty much all of the vendors provide gooberware to assist with installation and configuration of their software. You can choose to believe me or not, I won't lose any sleep either way. I can assure you that many vendors produce inferior SMP/E. SMP/E is a powerful tool, and when the SYSMODs are coded correctly, it makes installing and maintaining a system easy. When PTFs are sent without the REQs coded properly and the vendor tells me to BYPASS ID, I have to wonder why they bother with SMP at all. So you say. On the other hand, you could apply the same reasoning to vendor employees that you did to your own peers. They are just trying to do the best job they can for their customers. That's not all good or all bad. It just is the way it is. Installation aids may NOT be to your taste perhaps, but the vendors aren't providing them to p*ss you off and they're not all incompetent. Ask yourself why the vendors would bother doing all that extra junk if their customers weren't asking for it? It is all very well to say you don't like assistance from the autocurse software. Fine. I could care less. What I am really annoyed about is this constant blather that (all) vendors don't have a clue what they're doing. Perhaps you could do better, but I wouldn't bet a paycheck on it. CC -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
At 18:08 -0500 on 08/09/2006, Tom Marchant wrote about Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ): I can assure you that many vendors produce inferior SMP/E. SMP/E is a powerful tool, and when the SYSMODs are coded correctly, it makes installing and maintaining a system easy. That is until you have to RESTORE a SYSMOD at while point SMP/E causes you to do lots of useless work. The intent of a RESTORE is to create a system as if that SYSMOD (and possibly SYSMODs that PRE it) had not yet been APPLYed. The CORRECT way of doing a RESTORE operation is to determine which elements must be backed off and which SYSMODs contain the replacement versions of the elements. The current implementation causes you to have to remove (and subsequently reAPPLY) SYSMODS that have nothing to do with the one being RESTOREd. As a simple example, SYSMOD1 contains elements A, B, and C while SYSMOD2 contains only element B and PREs SYSMOD1. Both are currently in APPLY status. To RESTORE SYSMOD2, I must also RESTORE SYSMOD1 (and possibly SYSMOD3 which PREs SYSMOD1 since it contains a newer copy of A and/or C but not B). All that is needed is to just reAPPLY element B from SYSMOD1 and you have RESTOREd SYSMOD2 but SMP/E goes through useless work to back off A and C also (along with other elements in SYSMODs on the PRE chain that is anchored at SYSMOD1) only to then do an APPLY (sans SYSMOD2) of all the erroneously RESTOREd SYSMODs. If all you want to do is RESTORE B, you should run the element SUP chain on B until you find a copy to APPLY/use (in this case the copy in SYSMOD1) and ignore everything else. RESTORE is a flawed design since it involves elements that are not affected when the correct versions are available from SYSMODs still in APPLY status or from the DLIB copy of the element. -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
And what's the best way to put a private library dynamically in one's SYSEXEC concatenation? Would that be LIBDEF? ALTLIB. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Mon, 7 Aug 2006 23:28:32 -0600, Paul Gilmartin [EMAIL PROTECTED] wrote: Could this be automated? In, e.g., Mark's putative CHGIT macro, to 'X' all lines containing '//*' before doing the CHANGE ALL X? I know; I need to RTFM. But I'd be grateful for a pointer to a command name. x all //* 1 3 -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Mon, 7 Aug 2006 16:28:40 -0600, Paul Gilmartin [EMAIL PROTECTED] wrote: It may take a little longer, but I don't mind going into each member and doing an ISPF CHANGE ALL command for tape_unt and vend_hlq to whatever I need. If I know I will do a lot of this At least two contributors to this thread would take umbrage at those subjects which use minuscules. Each to their own. I don't mind the lower case because my change command will change it to upper. But if it would make everyone happy, there is nothing wrong with it being in upper case (VEND_HLQ) as long as it's unique so something doesn't accidently get changed. I just set up a quick and dirty CHGIT edit macro and use that when I edit the sample member before submitting / saving it. Would it help if the vendor supplied a sample CHGIT? Sure. It would save me the time it takes to look through some of the install sample jobs and see what variables need to be changed. Make sure you explain that it needs to go in a SYSPROC/SYSEXEC lib or supply another clist/exec that can be executed directly to set up a ALTLIB. Back to the autocust installs... Some vendors who supply them also provide alternate install instructions to do it the way I prefer. That is a great alternative since it lets me choose one way and someone else choose another way. In my experience, it seems jr. sysprogs seem to like those sort of things more than experienced sysprogs who understand what the jobs are doing better (like setting up an smp/e environment with a certain set of options etc.). 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Mon, 7 Aug 2006 18:37:26 -0500, Tom Marchant [EMAIL PROTECTED] wrote: Still, it would be nice if the vendors would use set symbols and include a member in all the jobs so that the symbols could be set in one place. What would you do for SYSIN? Typically install jobs contain (at a minimum) IDCAMS DELETE/DEFINE for VSAM SMP/E CSIs, DDDEFs, etc. 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Tuesday, August 08, 2006 8:13 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ) On Mon, 7 Aug 2006 18:37:26 -0500, Tom Marchant [EMAIL PROTECTED] wrote: Still, it would be nice if the vendors would use set symbols and include a member in all the jobs so that the symbols could be set in one place. What would you do for SYSIN? Typically install jobs contain (at a minimum) IDCAMS DELETE/DEFINE for VSAM SMP/E CSIs, DDDEFs, etc. Mark -- This is why I like ISPF file tailoring. I don't understand the resistance that I've felt from some of the other posts. ISPF file tailoring can be used to create instream parameters or to create a number of PDS control members. The ISPF dialog just asks for the customization parameters (ISPF variable values) and does a number of FTINCLs. Of course, I am not a developer, so I may well be missing something. -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, August 08, 2006 8:21 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ) snip Of course, I am not a developer, so I may well be missing something. snip As a developer, I have to prepare for a client to run on various levels of the operating system. Some with some without using SMS management. Some are running JES3, most aren't. Some are using RACF some are using ACF2 some have their own home grown systems, so SAF doesn't solve it all. Some customers are running other ISV products that interfere with what the product I work on does. So to give you a fast answer about upper/lower, use CLIST over REXX, program in C/C++ or ALC, just doesn't cut it. JCL is a pain because JES3 expects one thing, JES2 allows another, the internal reader handles things differently (so if I want to submit from within a customizer job...). And then the idea that ISVs don't know SMP/E is a bit out there -- well I'd hope that ISVs know SMP/E. But the reason for autocurst was to allow the customer to immediately install AutoOPERATOR and then install the SMP/E stuff later (basically the system came pre-installed you loaded the SMP/E files/system later so you could put on maint). So there are lots of things that vendors have to take into consideration, and the biggest one today are the Sr. Systems Programmers who don't know what a USERMOD is or a JES exit. 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
In a recent note, Tom Marchant said: Date: Tue, 8 Aug 2006 07:11:09 -0500 x all //* 1 3 Thanks. And now a little mystery. The test macro: /* Rexx */ signal on novalue; /* */ trace R address 'ISREDIT' 'MACRO (EARGS)' /* Make no changes in comments. */ 'EXCLUDE //* ALL 1 3' exit( RC ) excludes the first line (the JOB statement) as well as all comments. If I issue the same command from the command line rather than a macro, the JOB statement is not excluded. If I quote the target string: 'EXCLUDE ''//*'' ALL 1 3' the JOB statement is (correctly) not excluded. z/OS 1.5 ??? -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Tue, 8 Aug 2006 10:03:24 -0400, Thompson, Steve (SCI TW) [EMAIL PROTECTED] wrote: And then the idea that ISVs don't know SMP/E is a bit out there -- well I'd hope that ISVs know SMP/E. I'd hope so too, but some vendors consistently do it wrong. Some examples: Providing PTFs without proper PREs Providing PTFs that don't SUP when they should Routinely asking a customer to use BYPASS ID PTF A has a PRE on FMID B, but FMID B has a SUP on PTF A Failure to provide UCLIN to create DDDEFs I'm sure others will chime in with their pet peeve of the day. But the reason for autocurst was to allow the customer to immediately install AutoOPERATOR and then install the SMP/E stuff later (basically the system came pre-installed you loaded the SMP/E files/system later so you could put on maint). So I get a product that may match what SMP/E has. No, thanks. A properly built SMP/E install doesn't take much longer than just unloading data sets and then I *know* that they are in sync. The total amount of work is typically less to set up the SMP/E environment properly and then install. So there are lots of things that vendors have to take into consideration, and the biggest one today are the Sr. Systems Programmers who don't know what a USERMOD is or a JES exit. Now there's a statement that I think is a bit out there. 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant Sent: Tuesday, August 08, 2006 11:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ) On Tue, 8 Aug 2006 10:03:24 -0400, Thompson, Steve (SCI TW) [EMAIL PROTECTED] wrote: And then the idea that ISVs don't know SMP/E is a bit out there -- well I'd hope that ISVs know SMP/E. I'd hope so too, but some vendors consistently do it wrong. Some examples: Providing PTFs without proper PREs Providing PTFs that don't SUP when they should Routinely asking a customer to use BYPASS ID PTF A has a PRE on FMID B, but FMID B has a SUP on PTF A Failure to provide UCLIN to create DDDEFs I'm sure others will chime in with their pet peeve of the day. snip You have a point there. If they actually don't have SMP/E knowledgeable people. But sometimes the internal system that is used to generate APAR/PTFs gets screwed. And it takes a while to fix it. It even happened at IBM. But I have experienced this with some small ISVs where it takes them a while to get it all together. snip But the reason for autocurst was to allow the customer to immediately install AutoOPERATOR and then install the SMP/E stuff later (basically the system came pre-installed you loaded the SMP/E files/system later so you could put on maint). So I get a product that may match what SMP/E has. No, thanks. A properly built SMP/E install doesn't take much longer than just unloading data sets and then I *know* that they are in sync. The total amount of work is typically less to set up the SMP/E environment properly and then install. snip Ok, let's try this again. You get two tapes. First tape is an IEBCOPY install so that you can get the product up and running NOW. The second (which is overflow from the first actually) is ALL the SMPE files (kind of a snapshot of the system that was used to produce these tapes). This means that you have a RUNNING system that MATCHES the SMP/E files (including the CSI). The first files unloaded were the TARGET files of the SMP/E system that you haven't yet unloaded from the tape. And when I say RUNNING, it was a copy of an installed system where the install had been started and run (as part of the QA process). And, BTW, Boole Babbage didn't exactly dream that one up. I believe that actually came from a user group meeting where it was requested. It allowed a new install to be done immediately -- some customers apparently decided that they would re-order the product and use this method to install thereby offloading ALL the SMP/E work to Boole Babbage. Of course, best laid plans of mice and men and all that, there would eventually be a HiPER... snip So there are lots of things that vendors have to take into consideration, and the biggest one today are the Sr. Systems Programmers who don't know what a USERMOD is or a JES exit. Now there's a statement that I think is a bit out there. snip You should take some of the calls I have had to handle. Or wind up doing sysprog contract work (I have off and on for the past 7 years). You would be astonished at how depleted of skills some shops are after their management decided that the mainframe is dead. So people with 3 years experience are suddenly a Sr. Systems Programmer. A few of those shops that tried to kill their mainframe I've had the last laugh as I watched a CEO and a CIO get shown the door while the BOD was scrambling to re-hire the old mainframers (one of those companies was involved in bringing you the NE Blackout a few years ago). Later, Steve Thompson 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Tue, 8 Aug 2006 13:36:25 -0400, Thompson, Steve (SCI TW) [EMAIL PROTECTED] wrote: So there are lots of things that vendors have to take into consideration, and the biggest one today are the Sr. Systems Programmers who don't know what a USERMOD is or a JES exit. Now there's a statement that I think is a bit out there. snip You should take some of the calls I have had to handle. Or wind up doing sysprog contract work (I have off and on for the past 7 years). You would be astonished at how depleted of skills some shops are after their management decided that the mainframe is dead. So people with 3 years experience are suddenly a Sr. Systems Programmer. Now I understand You were referring to Junior Systems Programmers with a title of Senior. -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Tue, 8 Aug 2006 11:41:44 -0500, Tom Marchant wrote: On Tue, 8 Aug 2006 10:03:24 -0400, Thompson, Steve (SCI TW) wrote: And then the idea that ISVs don't know SMP/E is a bit out there -- well I'd hope that ISVs know SMP/E. I'd hope so too, but some vendors consistently do it wrong. Some examples: Providing PTFs without proper PREs Providing PTFs that don't SUP when they should Routinely asking a customer to use BYPASS ID PTF A has a PRE on FMID B, but FMID B has a SUP on PTF A Failure to provide UCLIN to create DDDEFs Hey, I recognize that 2-letter-name vendor by those clues - probably nearly all of us can recognize it. So there are lots of things that vendors have to take into consideration, and the biggest one today are the Sr. Systems Programmers who don't know what a USERMOD is or a JES exit. Now there's a statement that I think is a bit out there. I took exception to Steve's statement, too, at first. Then I considered a site or two near me where they are absolutely allergic to exits (and nearly allergic to USERMODs) and I have to say that I understand Steve's position a little better. 'Course, most of that allergy comes from a lack of knowledge and trust in the Sr. SysProg's assembler (and general) programming skills. There are too many z/OS Systems Administrators in the field today. Now it looks like IBM plans to build 20,000 more in a few years?! Just what the customers do NOT need! (Hey, IBM, how about building 20,000 enlightened senior managers and executives for customers instead? THAT would be a worthwhile goal!) -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Tue, 8 Aug 2006 12:47:16 -0500, Tom Schmidt [EMAIL PROTECTED] wrote: Providing PTFs without proper PREs Providing PTFs that don't SUP when they should Routinely asking a customer to use BYPASS ID PTF A has a PRE on FMID B, but FMID B has a SUP on PTF A Failure to provide UCLIN to create DDDEFs Hey, I recognize that 2-letter-name vendor by those clues - probably nearly all of us can recognize it. I was thinking of a 3-letter name vendor 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
To be honest, I dislike all those autocust things. I never found that it made the install any easier. Same with the rest of them. Mostly front ends to SMP/E, to cover up for the fact that the vendor doesn't have a clue how to create proper SYSMODs. Let alone HOLDDATA. I can't speak for all vendors, but trust me the reason is NOT because the vendors don't know how to package SMP/E deliverables. There is (at least in the ones I have dealt with) a full SMP/E install under those covers. The autocurse installers exist because a significant number of customers ask (demand!) them. The ibm-main audience is not necessarily typical because there are a lot of customers who can't spell SMP/E let alone configure high end software products. CC -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On 8 Aug 2006 15:41:36 -0700, in bit.listserv.ibm-main you wrote: To be honest, I dislike all those autocust things. I never found that it made the install any easier. Same with the rest of them. Mostly front ends to SMP/E, to cover up for the fact that the vendor doesn't have a clue how to create proper SYSMODs. Let alone HOLDDATA. I can't speak for all vendors, but trust me the reason is NOT because the vendors don't know how to package SMP/E deliverables. There is (at least in the ones I have dealt with) a full SMP/E install under those covers. The autocurse installers exist because a significant number of customers ask (demand!) them. The ibm-main audience is not necessarily typical because there are a lot of customers who can't spell SMP/E let alone configure high end software products. Could people comment on the other IBM maintenance methodologies, the ones for VM, VSE, AIX and OS400 and how they compare to SMP/E? If anyone has relatively current knowledge of the Unisys A series or 2200 series methodologies those would be of interest. I have often felt that SMP/E got the job done but required a lot of manual effort on the part of the developers, left holes for the installers such as no good way to hand panel prepping or compilation in ISPF, and was generally arcane. While I like the ease of applying Windows fixes when they work, I am in a position of trusting the vendor more than I would like. CC -- 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
Vendor JCL (was: WHY IS JCL ALLERGIC ... )
In a recent note, Ted MacNEIL said: Date: Mon, 7 Aug 2006 19:50:55 + Ok. Ed doesn't get to vote. I'm a customer (but not of Ed's products) so I get to vote, and I vote for mixed case JCL. If it could be submitted successfuly, I would vote for it, too. But, as long as it cannot, I still say the vendors have to put up with it! By submitted successfuly do you mean that the distributed JCL should suffice to perform the installation (or whatever function), using the vendor's suggested data set names, with no editing whatever of the JCL members? Good point. It's what customers of desktop systems expect; why should mainframe customers settle for less? Of course there was a recent thread in IBM_MAIN (or a sibling forum?) expressing overwhelming opposition to vendors' compelling customers to use the vendors' chosen data set names. But I recognize the difference between suggestion and compulsion. And, here I'm a little uneasy that if we instruct our customers to CHANGE 'VENDOR.PREFIX' 'USER.PREFIX' ALL etc., _if_desired_, that the editing may have the effect of making unintended changes elswhere in the files that by happenstance match the pattern. This is a (feeble) argument for choosing unusual, even syntactically invalid subjects to change. (I've had this happen when a CHANGE ALL intended to modify a version-release digraph happened to change a BLKSIZE that contained the same two digits.) I'd be delighted to be able to supply an INCLUDE member with all the strings we invite customers to change provided as JCL symbols, so editing one line (no CHANGE ALL) would properly affect every DD statement in every step in every job template. And this makes me again ardently wish for symbol substitution in instream data sets, so that changing a single SET symbol could make synchronized changes in the DD statements and the UCLIN. -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, August 07, 2006 3:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Vendor JCL (was: WHY IS JCL ALLERGIC ... ) snip And, here I'm a little uneasy that if we instruct our customers to CHANGE 'VENDOR.PREFIX' 'USER.PREFIX' ALL etc., _if_desired_, that the editing may have the effect of making unintended changes elswhere in the files that by happenstance match the pattern. This is a (feeble) argument for choosing unusual, even syntactically invalid subjects to change. (I've had this happen when a CHANGE ALL intended to modify a version-release digraph happened to change a BLKSIZE that contained the same two digits.) I agree! I just did this with CA-OPS/MVS II r11. And I messed it up a bit. I'd be delighted to be able to supply an INCLUDE member with all the strings we invite customers to change provided as JCL symbols, so editing one line (no CHANGE ALL) would properly affect every DD statement in every step in every job template. And this makes me again ardently wish for symbol substitution in instream data sets, so that changing a single SET symbol could make synchronized changes in the DD statements and the UCLIN. -- gil -- BMC's installation customization procedure for Mainview is decent. There are times that I get upset with it, but not in a major way. Perhaps other vendors could do similarly? Basically, there is JCL with symbolics in it in one library. As you go though the panels in the installation dialog, customized members are stored in another library with those symbolics resolved to your input. You can then, usually, just submit the generated JCL. Since ISPF is basically a given for every installation, I don't know why a vendor couldn't just use standard ISPF file tailoring. Again, put the JCL in a second PDS with the same name as the original PDS. Let the user submit it then and their or later. If the vendor really wants to P.O. everybody, make his tailoring use Perl (or awk) under UNIX and keep everything in a UNIX filesystem subdirectory. No! Use m4 and lose all their customers. grin No, it's not Friday. -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
Since ISPF is basically a given for every installation, I don't know why a vendor couldn't just use standard ISPF file tailoring. Again, put the JCL in a second PDS with the same name as the original PDS. Let the user submit it then and their or later. Be careful what you wish for. That BMC thingie you're referring to (Autocust) does in fact use ordinary ISPF file tailoring, but it is embedded in an almost insane maze of clist, rexx and ispf gooberware. It got that way from years of well intentioned meddling by folks without the knowledge or time to do it right. It has so very many ways to astonish and (ahem) delight you. If you like it, you just haven't used it enough :-) My friend Bill Blair has been busting his butt for months to beat it into shape. He is still scratching his head over it and he's one of the smartest guys I have ever met. CC -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Craddock, Chris Sent: Monday, August 07, 2006 4:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ) snip Be careful what you wish for. That BMC thingie you're referring to (Autocust) does in fact use ordinary ISPF file tailoring, but it is embedded in an almost insane maze of clist, rexx and ispf gooberware. It got that way from years of well intentioned meddling by folks without the knowledge or time to do it right. snip Affectionately known as autocurst by those of us who had the pleasure of having to fix it (and it had to be made aware of ISPF releases, TSO/E levels, MVS levels, etc. ab nauseum). Later, Steve Thompson Droole Babble Alumi -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
Affectionately known as autocurst To be honest, I dislike all those autocust things. Going way back to CA-Activator. Some work better and are easier to use than others, but I always want to review my JCL and save it in some sort of install library anyway (usually with names like #INST01, #INST02, etc.. so I can trash the whole thing and start over easily or so it makes it easy to see what order I did things in the next time). I just don't trust them. It may take a little longer, but I don't mind going into each member and doing an ISPF CHANGE ALL command for tape_unt and vend_hlq to whatever I need. If I know I will do a lot of this I just set up a quick and dirty CHGIT edit macro and use that when I edit the sample member before submitting / saving it. 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
In a recent note, Mark Zelden said: Date: Mon, 7 Aug 2006 16:54:03 -0500 It may take a little longer, but I don't mind going into each member and doing an ISPF CHANGE ALL command for tape_unt and vend_hlq to whatever I need. If I know I will do a lot of this At least two contributors to this thread would take umbrage at those subjects which use minuscules. I just set up a quick and dirty CHGIT edit macro and use that when I edit the sample member before submitting / saving it. Would it help if the vendor supplied a sample CHGIT? -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Mon, 7 Aug 2006 16:54:03 -0500, Mark Zelden [EMAIL PROTECTED] wrote: Affectionately known as autocurst To be honest, I dislike all those autocust things. Going way back to CA-Activator. Some work better and are easier to use than others, but I always want to review my JCL and save it in some sort of install library anyway (usually with names like #INST01, #INST02, etc.. so I can trash the whole thing and start over easily or so it makes it easy to see what order I did things in the next time). I just don't trust them. ... Those that let you examine and save the resulting JCL are the good ones. I often find the canned procedures don't quite allow the tailoring needed. If they don't allow modification of the built JCL, the JCL is often useless. (If they do allow modification, they obviously allow saving.) And, of course, no 2 vendors use the same tailoring process. It may take a little longer, but I don't mind going into each member and doing an ISPF CHANGE ALL command for tape_unt and vend_hlq to whatever I need. If I know I will do a lot of this I just set up a quick and dirty CHGIT edit macro and use that when I edit the sample member before submitting / saving it. ... If the symbolic substitution suggested earlier in this thread were supported there would be much less need for tailoring tools like CHGIT. Of course there would still be vendors insisting on saving us trouble by providing their own (unneeded) installation tools, producing unusable JCL. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
On Mon, 7 Aug 2006 16:54:03 -0500, Mark Zelden [EMAIL PROTECTED] wrote: Affectionately known as autocurst To be honest, I dislike all those autocust things. Going way back to CA-Activator. Some work better and are easier to use than others, but I always want to review my JCL and save it in some sort of install library anyway (usually with names like #INST01, #INST02, etc.. so I can trash the whole thing and start over easily or so it makes it easy to see what order I did things in the next time). I just don't trust them. Yes, Aggrivator. I never found that it made the install any easier. Same with the rest of them. Mostly front ends to SMP/E, to cover up for the fact that the vendor doesn't have a clue how to create proper SYSMODs. Let alone HOLDDATA. It may take a little longer, but I don't mind going into each member and doing an ISPF CHANGE ALL command for tape_unt and vend_hlq to whatever I need. If I know I will do a lot of this I just set up a quick and dirty CHGIT edit macro and use that when I edit the sample member before submitting / saving it. Still, it would be nice if the vendors would use set symbols and include a member in all the jobs so that the symbols could be set in one place. 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
At 16:54 -0500 on 08/07/2006, =?ISO-8859-1?Q?Mark_Zelden?= wrote about Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ): It may take a little longer, but I don't mind going into each member and doing an ISPF CHANGE ALL command for tape_unt and vend_hlq to whatever I need. The problem with that is you also change the comments at the start of the job. I go the Change All route but FIRST do an xx...xx on the JCL (ie: Past the Comments) and then use CHANGE ALL X (so as to ignore the comment block). -- 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: Vendor JCL (was: WHY IS JCL ALLERGIC ... )
In a recent note, Robert A. Rosenberg said: Date: Tue, 8 Aug 2006 00:21:06 -0400 At 16:54 -0500 on 08/07/2006, =?ISO-8859-1?Q?Mark_Zelden?= wrote about Re: Vendor JCL (was: WHY IS JCL ALLERGIC ... ): It may take a little longer, but I don't mind going into each member and doing an ISPF CHANGE ALL command for tape_unt and vend_hlq to whatever I need. The problem with that is you also change the comments at the start of the job. I go the Change All route but FIRST do an xx...xx on the JCL (ie: Past the Comments) and then use CHANGE ALL X (so as to ignore the comment block). Could this be automated? In, e.g., Mark's putative CHGIT macro, to 'X' all lines containing '//*' before doing the CHANGE ALL X? I know; I need to RTFM. But I'd be grateful for a pointer to a command name. And what's the best way to put a private library dynamically in one's SYSEXEC concatenation? Would that be LIBDEF? Thanks, 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
