Re: What is a programming language? (WAS Re: Unix systems and Serialization mechanism)
Is GAL a programming language? What about the old SimPC script language? Do such things really qualify to be called "Programming" languages? I think this comes down to what you consider is programming. On Fri, Jul 2, 2010 at 8:26 PM, zMan wrote: > FWIW, it never occurred to me that it *wasn't* a programming language. But > when I referred to it as such a few years ago, I got lambasted by some > (only > some!) of my then-cow-orkers. So Ted, you and I agree on something! > > On Fri, Jul 2, 2010 at 5:48 PM, Ted MacNEIL wrote: > > > >OK, it's Friday afternoon, so time to broaden this a bit: Is HTML a > > programming language? > > > > By definition, I would say yes. > > And, I don't think this is a 'Friday' topic. > > > > After all, without programming languages, we wouldn't need computers. > > > -- > zMan -- "I've got a mainframe and I'm not afraid to use it" > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I am looking for a “poor man automation"
You have got quite a few options for this. what is available depends on whether you just want message automation or also scheduling. You should look at the following: TSSO (Free from CBT tape, but requires some knowledge to build) Write MPF exits (I bet a dozen people on here would show you how) Brian Westerman's Syzygy products are a good bet if you do not want to get involved in building TSSO. He is a major contributor to it. Exspans Systems have a range of inexpensive products that cover scheduling and console automation. What you choose depends on your requirements. To get a better idea of what we should point you at you need to give us more information about what you want to do and the level of sophistication you want of your control. Also, do you want to start, stop and control the whole system. Do you want something that allows you to start simple and grow it as you see your requirements increase. Also, how much time effort and expense do you want to put into it. Try to answer some of these questions and I will bet that any amount of good advice will come your way. On Tue, Sep 29, 2009 at 6:15 AM, Jan MOEYERSONS wrote: > On Mon, 28 Sep 2009 08:02:59 -0700, Shahnaz > wrote: > > > > >Any tips will be great (e.g., exit points, shareware, etc.) > > > > CBT tape? > http://cbttape.org > > Cheers, > > Jantje. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSLOG message suppression
Turn on the no hardcopy bit in the message flagbytes 2 OICTXTRFB2,CTXTRNHC FORCE NO HARDCOPY This will display it on the console but not on syslog or OICTXTRFB2,CTXTRDTMDELETE THE MESSAGE This will not display on the console or on syslog On Fri, Sep 18, 2009 at 8:06 PM, Bob Rutledge wrote: > John Norgauer wrote: > ... > >> What is needed in the MPFLSTXX parm to suppress messages going to SYSLOG? >> > ... > > I do not recommend this on anything but a standalone sandbox system; it > falls under the category of tampering with evidence and an auditor would > frown loudly. > > That said, the literal answer to your question is "a USEREXIT parameter > naming an exit that sets CTXTRDTM". The method is described the > Installation Exits manual. > > Bob > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Question about MPFLSTXX
An MPF exit can be used to recognize and respond to any message, whether it has spaces or not in the area normally considered to be a message ID. I know this because we use an automation product called AutoMan from Exspans that allows us to define message IDs and by placing the text in quotes, messages that do not have an ID, and has spaces in it. For instance you can define a message to be suppressed by MSG=IEF049I SET DISPLAY=SUPPRESS or MSG='* RETURN COUNT" SET DISPLAY=SUPPRESS The first example defines a message with an ID and the second one defines an application message from a COBOL DISPLAY command. In both cases the action is to suppress the message from the console. This product uses the MPF exit to perform. On Wed, Sep 16, 2009 at 3:12 PM, Bob Rutledge wrote: > Yes, it has to have a message ID, the definition of which is in the > Init&Tuning Ref. Essentially, it's the first ten non-blank characters. > I've got one that reads > > DATA/INDEX,SUP(YES),RETAIN(YES) > > Bob > > John Norgauer wrote: > >> Can the MPFLSTXX member be used to suppress any display on the >> console/hardcopy or does it have to have an actual message ID? >> >> Thanks >> > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How often IPL a production LPAR (any good practice)
I thought everyone used automated IPL procedures these days. Was P&H sometime ago? On Thu, Sep 3, 2009 at 10:55 AM, Eric Bielefeld wrote: > When I worked at P&H Mining, we IPL'd every Saturday. That worked very > well, as at 6:00 PM they shut down all of the onlines and did backups. To > shut down and IPL just added about 15 minutes. One big advantage to IPLing > every week is that the operators know how to do it. They deal with it every > week. When you IPL once a quarter or less, the operators forget. We were > manufacturing, which isn't near as critical to keep the system up 24/7, > although occasionally when the factory was really busy, we would skip the > IPL because they were running the factory on the weekend also. > > I think IPLing more regularly keeps some things less fragmented, although I > doubt if that causes any real problems. Business need, as several have > said, should dictate how often you IPL. Certainly, changing releases of > z/OS requires an IPL, and major maintenance should be done with an IPL. > > Eric Bielefeld > Sr. Systems Programmer > Milwaukee, Wisconsin > 414-475-7434 > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ist663i suppression
Yes I agree. We had to give up Netview and we installed AutoMan in its place, and had to do the same kind of thing. We wrote a counter script that counted the number of times the message was displayed for a resource and suppressed it until the counter was triggered for that resource. It is not a difficult script, you just have to think about exactly what you want to achieve first. Simply suppressing all occurrences is straight forward and takes no effort at all. But controlling it takes a bit more thought, because there are several different ways to do it, and the method chosen needs to be a model for other similar things that may crop up in future. On Sat, Sep 5, 2009 at 3:40 PM, Patrick O'Keefe wrote: > Sorry for the late response. I was out of town last week (and will be > again by the time this is read, probably). > > > On Sun, 30 Aug 2009 09:36:51 -0500, Chris Mason > wrote: > > >... > > > >However, the right way to go about suppressing the IST663I message > >and all the following messages in the message group is first to work > >out why the messages are there in the first place and then deal with > >the problem which causes them to be created. > > But as Chris says in a later post, this may not be possible. > > >... > >I'm assuming that at some time in the past somebody noticed that >there > were a lot of IST663I messages and, rather than bother about > >why they were being created, ... > > ... or knew there was no easy or desirable way to eliminate their > creation ... > > >..."cleverly" recalled that the quick way to deal with unwanted > >messages was to use the NetView "Message Automation Table" (MAT), > >forgetting that the purpose of the NetView MAT was to get rid of > > messages which didn't really matter ... > > ... or perhaps "remembering" rather than "forgetting". > > The NetView solution, in fact, works well if NetView is running with its > Primary Programmer Operator function enabled. VTAM will pass most > its messages to NetView across the PPO interface rather than issuing > a WTO (thus keeping the messages from SYSLOG/OPERLOG). NetView > then has a number of message-handling options: it (rather than VTAM) > can issue a WTO for the message, and/or it can write the message to the > NetView log, and/or it can automate the message, etc. as specified in > NetView's automation table. > > In the past NetView's ability to reference information from multiple > lines of a multi-line message was very limited. This was improved > a few releases ago with the automation function ACQUIRE. > > One of the real advantages of using NetView to manage IST633I > messages is the ability reduce the number of the IST663Is displayed > based on the resource name or type: every 10th message for some > resources; every 100the for another; no IST633Is for yet another. > > Unfortunately, NetView provides no straightforward ability to request > (for example) one IST633I messages every 10 minutes for some > resource. Don't bother looking for it; it doesn't exist. THRESHOLD > sounds like the solution. It isn't. :-( > > Pat O'Keefe > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TSSO in a sysplex
Hi Dana, we had a similar problem and looked at both freeware and alternative low cost solutions for this. In our case we have two CEC each with four LPARs. After experimenting with TSSO our management rejected it, because we could not afford to make a system programmer resource available to update and maintain it. I believe that it may be possible to re-write some of the code to do this, but I was told to leave it and instead concentrate on looking at alternative technologies. There are some very credible programs out there that you may wish to look at which can be downloaded from the internet. You may have to do a google search to find them, but take a look for Szyzgy and Exspans AutoMan. The Szygy product is a very credible replacement for TSSO and the Exspans product is popular in Europe as a replacement for Netview. In the end we did chose one of these and have been happily using it for a couple years now. The big advantage is the level of support that we got for setup, we never technical problems, and really only needed advice on the best ways to do things. On Tue, Aug 11, 2009 at 7:59 PM, Dana Mitchell wrote: > Hello, > We are considering replacing Netview for simple message automation with > TSSO > from the CBT tape. I have it up and running successfully but I have one > question. Currently we have two Netview subsystems running on two members > of a sysplex, each processing messages from a subset of sysplex members. > Is there a way to duplicate this setup, having TSSO process only messages > from a subset of sysplex members? or alternately, be able to identify > what > system a message was issued from in TSSO processing? > > thanks > Dana > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Any gotchas going from 1.4 to 1.9?
Watch out for problems due to VSM ALLOWUSERKEYCSA. The default changes to NO. When you first change over set this to YES, test your system , then let it default and see what no longer works. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Messages as Programming Interfaces
Our automation system relies heavily on the content of messages and has not failed us in 10 versions of z/OS. We have an automation product that reads the text of messages and enables the execution of tasks, depending on the text and passing extract of text to subroutines. I have never seen a directive against this practice. On Mon, Jul 6, 2009 at 9:07 PM, Paul Gilmartin wrote: > It is my understanding that IBM discourages the use of > message texts as programming interfaces. Can anyone > point me to a clear statement of this in IBM documentation? > > (Notwithstanding that IBM is very reluctant to change > messages lest that disrupt automated operations.) > > Thanks, > gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: job started with SUB=MSTR without the owner information
There is no jobid unless the task attaches to JES and requests one. The task itself must request the connection and cannot be assigned from the outside. On Fri, Jun 5, 2009 at 1:43 AM, Tommy Tsui wrote: > Hi all, > > I try to started a system task APPC with SUB=MSTR but can't find the > owner/user or jobid information even we defined a started task to > APPC.* . How can we assign a owner to this system task? > > > Any help will be appreciated > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Message Flood Automation in z/os 1.9
Is it easier to implement message flood the way IBM have implemented it or to use one of the message automation products that offer the MPF exit as one of its options? On Wed, Jul 1, 2009 at 4:07 PM, Klein, Kenneth wrote: > > > Actions for OA25602: > > Before the installation of this APAR, if you implemented > exit specified in parmlib member MPFLSTxx and with message > processing installation exit IEAVMXIT. With this APAR, > Message Flood Automation is integrated in z/OS, eliminating > the use for the exit routines. Message Flood Automation must > be removed from these exit routines: > > Steps to take: > > - Update your MPFLSTxx parmlib member to remove all > .CMD USEREXIT(CNZZCMXT) statements. > > - If you have a CONTROL M (K M) command in your CONSOLxx > or yout COMMNDxx, you must remove it. > > - If you use exit IEAVMXIT only for Message Flood > Automation, update your CONSOLxx parmlib member to > change the INIT statement option of UEXIT(Y) to > UEXIT(N). Note: Do not do this if you want to > continue to use IEAVMXIT for other > purposes. > > > Ken Klein > Sr. Systems Programmer > Kentucky Farm Bureau Insurance - Louisville > kenneth.kl...@kyfb.com > 502-495-5000 x7011 > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Skip Robinson > Sent: Wednesday, July 01, 2009 1:28 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Message Flood Automation in z/os 1.9 > > I don't have the HOLD data in front of me, but as I recall 'exit > removal' > referred only to message suppression logic, not to the exit per se. For > example, we use the exit to set message color by system, not for > suppression. The exit is still in place and working fine. I think the > HOLD record is poorly worded and misleading, but the gist is there if > you ponder it long enough. > > . > . > JO.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 626-302-7535 Office > 323-715-0595 Mobile > jo.skip.robin...@sce.com > > > > > "Klein, Kenneth" > > > FB.COM> > To > Sent by: IBM IBM-MAIN@bama.ua.edu > > Mainframe > cc > Discussion List > > Subject > .edu> Message Flood Automation in z/os > > 1.9 > > > > 07/01/2009 09:44 > > AM > > > > > > Please respond to > > IBM Mainframe > > Discussion List > > > .edu> > > > > > > > > > > The hold(action) states the userexit is to be removed from the mpflst, > and in consolxx the uexit be set to (N). > So how does the integrated mfa know which messages to suppress? > Any other actions required beyond whats in the hold data? > > > Ken Klein > Sr. Systems Programmer > Kentucky Farm Bureau Insurance - Louisville > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search > the archives at http://bama.ua.edu/archives/ibm-main.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Memory allocation
Use Matrix from Exspans. On Thu, Jun 18, 2009 at 2:31 PM, Ward, Mike S wrote: > Hello all, I have written an mq security exit for z/os in assembler that > works pretty well. What I would like to add is the capability to use > persistent memory. I tried to allocate memory from SUBPool 131 and 132. > I received a not authorized error. I have my module in an authorized > loadlib and linked with AC=1. I looked at CPool, and Hyperstorage as an > option but found them very confusing. Not for the light of heart anyway. > I like using the obtain because it seems simple enough. Can anyone help > me figure out how to allocate persistent memory? Thanks. > == > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity > to which they are addressed. If you have received this email in error > please notify the system manager. This message > contains confidential information and is intended only for the individual > named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please notify the > sender immediately by e-mail if you > have received this e-mail by mistake and delete this e-mail from your > system. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this > information is strictly prohibited. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Automating message CBR3750I
Don't know about doing it in OPS/MVS. We use AutoMan V2.9 and use the PARSE MSG command to parse the message and determine the format. On Fri, Jul 25, 2008 at 1:07 PM, Lizette Koehler <[EMAIL PROTECTED]>wrote: > We had an issue with a back end tape in our VTS getting an error. > > CBR3750I Message from library SCSVTS1: OP0122 Mount of logical volume > 527272 located on physical volume V00048 failed. (rc=8794) (VTS 1) > (07-02-2008 17:30:40). > > > Since this message varies in length and text, I was wondering if anyone > using OPS/MVS is currently monitoring this message for errors? And if so, > what tack did you take with it? > > Thanks > > Lizette > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > 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: Beta TEST announcement of Version 3 of SyzAUTO
Ted, this is basically what Brian uses this discussion group for, to advertise his products and services. On Fri, Mar 7, 2008 at 3:16 AM, Ted MacNEIL <[EMAIL PROTECTED]> wrote: > > apologize if you have already received the email on this, but Syzygy is > announcing our BETA testing of the next version of SyzAUTO. > > You should appologise for sending this e-mail at all! > IBM-Main is a user discussion forum. > Not a place to receive e-mail advertisements from software vendors. > > - > Too busy driving to stop for gas! > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > 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: How do you collect your Discribuetd systems jobs?
That is not completely true. Some intelligent schedulers also allow you to specify the disposition of work when it is complete. On Dec 16, 2007 10:15 AM, Kenneth E Tomiak <[EMAIL PROTECTED]> wrote: > Job schedulers merely kick off the work, so collecting the 'process' > output is > up to the process to get the output where you want it stored. In one > installation we used FTP to put the AIX process output up on OS/390. > > From there, you could then run another job to put it in a SYSOUT dataset > if > that is where you need it. RMDS, $AVERS, and other products can store your > report output. And from z/OS you can then either push out reports or > emails in > various formats, including PDF attachments. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > 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: How do you collect your Discribuetd systems jobs?
We have just started to use the SPOOL command of our automation tool (AutoMan) to send sysout by email. On Dec 13, 2007 4:53 PM, Jon Brock <[EMAIL PROTECTED]> wrote: > Similarly to Bruno, we schedule everything from z/OS, except that we use > CA-Scheduler instead of TWS. As for the sysout, we just leave it on the > individual machine concerned and browse it there at need. > > Jon > > > > > We use TWS ( OPCPLEX) on our Z/os Sysplex with end to end feature , we > schedule all jobs on distributed server from Z/os . > We currently schedule batch ( scripts) on AIX ( pseries ) Linux ( red > hat) > and quite a few Windows servers . > Using the OPC Data Store allows you to look at the output from sdsf > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > 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: PL/1 Storage Control Issue
Hi Rick, I cant point you at a reference, but I can tell you how we looked at a problem like that some years ago. You can UNSPEC the pointers into a variable, and display them to see where they are pointing. On Dec 10, 2007 11:37 AM, Rick Fochtman <[EMAIL PROTECTED]> wrote: > Can anyone point me to a reference that describes in detail the various > storage control blocks used by PL/1 in managing BASED storage entities? > > I have an application that's running out of storage, supposedly, far too > soon, even with REGION=0M. The number of entities that lead to failure > leads me to believe that the BASED elements are all being held in 24-bit > addressable storage. This is NOT a UNIX-style application, if that makes > any difference. The compiler is IEL00. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > 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: Shooting of Commands
This is not really an appropriate forum for people threatening each other. If you want to fight with each other you should do it in private. If my boss here at the Ministry sees this kind of exchange, he will order us to stop experimenting with code from CBT. He will also black list all the three products mentioned, and not allow us to continue with our license of one of the mentioned products next year, despite the fact that it is clearly the best possible solution to our problem. He will react to the name, and completely ignore the fact that we have licensed a much later and more complete solution than the one distributed on CBT. If there is any suggestion of impropriety at all, I will have to look for a new automation solution, and its manufacturer will undoubtedly be as unhappy as Mr. Westerman presents himself as being. On Nov 26, 2007 1:32 AM, Brian Westerman <[EMAIL PROTECTED]> wrote: > Hi Glenn, > > Your comments have (so far) caused more than 30 customers to send me email > with copies of what you have said about my utilities and (incidentally) > about me. I have also received several phone calls and some email from > other members of this list who are not customers of mine, and it might be a > good idea for you to think before you make false statements, insinuations or > accusations. > > Actually The Automatic Command and the Command scripting facilitites predate > your code by almost 20 and 10 years respectively. They have been renamed > from their original names, several times over the years and the code has > been updated to support newer levels of the OS and to perform a great number > of new functions. There actually was some code in the command scripting > program which was copied (with permission) from someone else, but that also > predates your code by many years so that code can't possibly infringe on > anyone's code. > > Your code MPFXTALL is actually very close to albeit a less elegantly > implemented TSSO substitute, but you don't see me denigrating you or your > abilities to the rest of IBMMAIN about that. You have the right to write > any code you want and offer it in any way you see fit. Please remember that > other people also have that same right. When someone uses my code that I > have provided freely, in its entirety or in part, it's not considered > copyright infringement, you can't infringe on a copyright that doesn't > exist. What could you possibly have been thinking when you said what you > said? > > I have been writing code for IBM, and many non-IBM vendors for a very long > time. There are several routines and parts of sub-systems that you use > every day on z/OS, assuming you have a job working with z/OS, that were > written by me. I have been contributing code to SHARE and CBT and many > other places for a LONG long time, and I still submit source code for people > to share and to help them learn how to code things for themselves. > > The fact that I no longer share the SOME of the code for several of the > utilities we support has nothing to do with anything except the economics of > the situation. There are currently over 1,700 ACTIVE utilities and programs > that I personally have written with a combined well over 700,000 currently > active lines of code, (and probably more than twice that in the > in-active/obsolete code that I still keep around "just-in-case"). I even > have code that I wrote just to keep track of my code. :) > > Some of my code is not shared because of the time and effort involved in > testing, updating and keeping the code functioning at a level that makes no > compromises and is reliable, sometimes it's because the code is too > dangerous to provide to people who might not have the skills level to use it > properly. Sometimes it's because the code is just so cool that I feel that > it's worthy of being marketed. :) It has nothing to do with hiding code > from other people. The sad fact is that there are very few people > now-a-days that even know how to code effectively in assembler, and the pool > keeps getting smaller. > > I'm a bit distressed by your insinuation that there might be some copyright > infringement going on because my code isn't copied from anyone, especially > not you, as your coding techniques are not on the same level as mine. > Although my code has obviously been copied time and time again, but that's > what I contribute it to be used for. If people are copying your code, and > you don't like it, then remove it from CBT. I'm sure no one is forcing you > to keep it there. > > You might want to remember in the future about the possible cost of making > these kinds of accusations. Not everyone is as easy going as I am and I'm > sure you don't want to get a letter from someones lawyer, especially not > mine because he is NOT a very nice person. It can get quite expensive for > you. > > At first I was offended by what you said, then I realized how silly it was > for you to make that accusation, based on what
Re: VARY too many devices offline
Yes, I quite agree with you. At our organization we do brainstorm about what could potentially go wrong and we admit that humans are error prone for a whole variety of reasons. So we do try to have contingencies planned as well as procedures to catch gross errors. My management is very strict that we should present the benefits and drawbacks of all of our procedures, and consider what could go wrong. Sometimes this makes us slow to implement new systems, but they do tend to be quite reliable. But they have to be, because many people depend upon our services, including the dispatch of police and ambulances, as well as payrolls for public services. On 10/23/07, Howard Brazee <[EMAIL PROTECTED]> wrote: > > On 22 Oct 2007 14:12:07 -0700, [EMAIL PROTECTED] (Zahir Hemini) > wrote: > > >This is exactly why there are products like CA OPS/MVS and Automan and > >probably a few others. People sometimes are new to a procedure, they do > >accidentally make mistakes, and read and write instructions incorrectly. > > Which is the response to the message that compared operator errors > with blood tester errors. > > People do make mistakes. When the results of likely mistakes are too > expensive, procedures and tools need to be created to minimize the > impact of those mistakes. > > Lots of software design is like the design of sidewalks which have > lines scored on them to encourage the breaks into a predictable > direction. Don't deny that errors happen- handle them. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > 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: VARY too many devices offline
This is exactly why there are products like CA OPS/MVS and Automan and probably a few others. People sometimes are new to a procedure, they do accidentally make mistakes, and read and write instructions incorrectly. It is up to the systems management to make sure that proper process is in place to catch and disallow mistakes that will bring the systems down. It is perfectly legitimate to specify procedures that require certain devices to always be online, or online at specific times and dates. It is reasonable that these are documented and embedded into software procedures to ensure that they are adhered to. The operator should not be fired, but given education. The systems management that allowed this to happen are a better candidate for dismissal. On 10/22/07, Howard Brazee <[EMAIL PROTECTED]> wrote: > > On 22 Oct 2007 12:56:30 -0700, [EMAIL PROTECTED] (Jon Brock) wrote: > > >Color me disbelieving. > > > >I think in the 30+ years I have been around OS360 and MVS and z/os, > >there has never been an operator mistake of a typo. > > I liked the time where the Vax operator put in a date a century in the > future. DIR SINCE TOMORROW found the file I created before I called > him. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > 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: Netview DM PK07855
Yes. You cant do it. The one byte console ID is dropped. On 7/16/07, Sharon Lopez <[EMAIL PROTECTED]> wrote: We are scheduled to migrate all our production systems to z/OS 1.8 and we still have an open apar with NETVIEW DM with the one-byte console id. Has this stopped anyone from migrating forward to 1.8? -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Software installs which deserve an "A+"
There are a few. AutoMan is like that too. On 5/24/07, John Mattson <[EMAIL PROTECTED]> wrote: I know it is against "policy" to praise rather than disparage, but occasionally a software vendor comes up with an install that really works quite nicely. DTS www.dtssoftware.com SRS product is a good example. One basic assumption is that you have the ability to FTP from your PC to your mainframe. You download their ZIP file to windows and unzip it. Then you create an MVS JOB card in a text file and then run their FTPINST.BAT passing it just 6 parms (see below). rem * A sample JOBCARD.TXT file: rem * rem * //JOBNAME JOB REGION=1M,USER=userid,PASSWORD=password rem * /*ROUTE PRINT FETCH rem * rem * rem * After creating the jobcard.txt file, you can issue the ftpinst rem * command. This batch file has six positional parameters. rem * rem * Parm 1 - HLQ of DTS distribution libraries. Note: This parameter rem * can contain multiple qualifiers (ie. VENDOR.DTS) rem * Parm 2 - IP address or Domain name of the MVS FTP Server rem * Parm 3 - TSO Userid for logon rem * Parm 4 - TSO Password for logon rem * Parm 5 - Volume name for new allocations rem * Parm 6 - Name and location of the member containing the JOB rem * card information (ie. c:\temp\jobcard.txt). rem * rem * Sample execution: rem * rem * ftpinst DTS 199.72.47.195 USR1 PASS1 DTS001 JOBCARD.TXT From this information they create an FTP script and FTP the XMIT files to your mainframe. They generate MVS JOB JCL to expand (RECEIVE) the XMIT files, and they FTP the jobs to the MF host and submit them to JES. At least in my shop it worked flawlessly. I liked it so much, I copied their BAT file and adapted it to other installs which are not so efficient. I do not see any Copyright notices on the scripts, but I am not going to take a chance of irritating the vendor. If anyone is interested in seeing the whole thing, I will ask DTS if I can send you a copy of the .BAT file. Just drop me an eMail. Or give DTS a call. -- For IBM-MAIN subscribe / signoff / archive access instructions, 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
