Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jul 11, 2005, at 4:15 PM, Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 07/08/2005 at 11:58 PM, Joe Zitzelberger [EMAIL PROTECTED] said: Then why did you write viewed through the eyes of ISPF, with a spool dataset listing when you meant viewed through the eyes of SDSF? The ISPF facility for viewing SPOOL output has nothing to do with SDSF. Yes. ISPF is one such tool. SDSF is a totally different one. No. SDSF is going to be the application. PKB. I understood it just fine; you were wrong, and don't seem to understand the difference between a facility of ISPF and a similar facility in SDSF. But ISPF never means SDSF. IBM has well documented in SDSF manuals, ISPF manuals and JES manuals the use of the ISPF Edit and Browse services from within SDSF. I'll save you the google, here are IBM's words on their quick reference card for SDSF: http://www.ibm.com/servers/eserver/zseries/zos/sdsf/pdf/ sdsfcard.pdf Note the part where it says Browse output using ISPF Browse, Browse output using ISPF Edit and Browse JCL using ISPF Edit. IBM's words, not mine. You are simply factually incorrect -- SDSF can and will invoke the actual ISPF Edit and Browse applications if ISPF is available. If I were a punny sort I might suggest you have failed to see the forest full of features because of all the pedan-trees. But when Bill K. says Bill K did not say that the message includes the hexadecimal value of the text in error. He did, however, say that the message could be improved. Perhaps you should pay closer attention to what he actually says instead of the spin that you wish to put upon it. I did not claim Bill said that. I said: You can rely on the 'compiler used to translate out non-displayables'. You even got me to question the behavior and test it. But when Bill K. says the compiler doesn't do that, it is very likely that the compiler doesn't do that. Your creative quoting has confused you. I cited Bill's refutation your frequently repeated assertion that the compiler translates out non-displayable chars. (Since you seemed quite unwilling to accept the results of my testing of this compiler behavior) And while I have suggested that the text seems quite self-documenting -- as all IBM Cobol compiler messages are -- my primary opposition has been to the idea of a Cobol MC manual. They tend to be a waste of time for compilers. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
In [EMAIL PROTECTED], on 07/05/2005 at 01:33 PM, Ed Gould [EMAIL PROTECTED] said: There is MC to submits A RCF for :) Good catch. You're right, of course, if the manual doesn't exist then there's no way to deal with an opaque message with an RCF, and level 2 will blow you away if you submit an ETR :-( -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jul 4, 2005, at 6:37 PM, Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 07/02/2005 at 12:05 AM, Joe Zitzelberger [EMAIL PROTECTED] said: That was viewing it with SDSF. Then why did you write ISPF? I didn't write ISPF -- I wrote viewed through the eyes of ISPF, with a spool dataset listing. It was in the context of a discussion of IBM supplied development tools available to view spool listings. Without considering the cool new options like WSAD or WSED, or even the slightly moldy options, like WSA, just plain vanilla ISPF Edit/ Browse is going to be the application that displays your data when you view a spool dataset listing. See, this is the problem that occurs when you take one small piece of something, perhaps a partial quote of an email, or perhaps the message number of a syntax error, and try to understand it without its context. Words mean things in relation to the other words around them, just as lexical elements in a source file have a relationship to the other lexical elements in the same source file. Trying to separate them can result in altered meanings and misunderstandings. If a person writing Cobol is not conversant with Cobol then the best thing that can happen to them is a Read the LRM message. No; such messages are singularly unhhelpful. It *might* be helpful to direct them to a specific section of the LRM. There is a section of the LRM named SHIFT-IN and another section named SHIFT-OUT that appear in the LRM Table of Contents. Each is as brief as any MC entry, perhaps half a page, but explains it in great detail. You think this is not enough? The message includes the row and column of the offending byte. As well as a description of its offense. FSVO description; it is one that was unintelligible to the programmers. In what possible way could you consider that 'unintelligible'? In all the ways that I have already explained. By the empirical evidence. On the contrary. Three non-Cobol programmers have chimed in, you, Ed G. and the OP have all said that it made sense to you. Even though you and EG would like an MC for use by the less-gifted. Two Cobol programmers, myself and Bill K., have chimed in that it made sense to us. No one has claimed that it was unintelligible. The OP only said: Our developers are getting IGYPS0157-E and IGYPS0158E messages when they try and compile a CICS COBOL programs... There was not a statement about their confusion with the text of the message. (I could see a valid complaint that it was an error level message instead of a warning. E-level messages might break compile procs, cause link steps to be bypassed, etc. -- this is bad behavior for a literal that was accepted as written.) But the message being unintelligible? No, that was not claimed. The listing already provides the 'bad text' with the message. Which part of in hexadecimal don't you understand? If you believe it is unnecessary, say so, but to claim that it is there is dishonest. You can rely on the compiler used to translate out non- displayables. You even got me to question the behavior and test it. But when Bill K. says the compiler doesn't do that, it is very likely that the compiler doesn't do that. He is, after all, one of the worlds leading authorities on Cobol. The value is clearly there in the listing. Your refusal to look at the value will not make it go away. (There might be a joke about Schrodinger's byte in there somewhere...) Using your theory above, one would think that a programmer moving from an APOS to a non-APOS shop would be paralyzed with fear at the sight of characters? You obviously don't un derstand my theory. What I really don't understand about your theory is that here: SM: ...and explain what hexadecimal data are, and how to display them, in terms understandable to a COBOL programmer? SM: How many COBOL programmers know about hexadecimal display? You say that Cobol programmers are clueless about what hexadecimal data are or how to view them. But here, you say that the hexadecimal value is helpful to resolving the problem and should be made available: SM: e.g., a quote in hex of the offending text SM: That's a lot less helpful than giving the value. If the Cobol programmer in question is so completely ignorant, as you suggest in the first case -- what makes you think the value you asked for in the second case would be of any use at all? Why do you assume any knowledge of DBCS is needed at all? Knowing that the Cobol reserved words SHIFT-IN/SHIFT-OUT are a pair that must appear together should be enough for anyone to fully understand this message. And that knowledge is provided by the existing text. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
In [EMAIL PROTECTED], on 07/01/2005 at 01:58 AM, Joe Zitzelberger [EMAIL PROTECTED] said: That is because it doesn't change. Which part of That certainly didn't use to be true, don't you understand? A check engine light is irrelevant if it does not appear on an auto dashboard. How can the exact byte location of the error, with surrounding source lines for context, be irrelevant to resolving the error? Beczuse the exact co0lumn is not and never was the issue; the issue is the nature of the error and the failure of the message to adequately explain it. The message includes the row and column of the offending byte. As well as a description of its offense. FSVO description; it is one that was unintelligible to the programmers. In what possible way could you consider that 'unintelligible'? In all the ways that I have already explained. By the empirical evidence. Why doesn't he/she look at what non-displayable data are in the text? I don't know. Why doesn't the message text suggest doing that, and explain what hexadecimal data are, and how to display them, in terms understandable to a COBOL programmer? They gave you the row and column. They gave you the figurative constant name. That's a lot less helpful than giving the value. Turning hex on will give you the value. The message text doesn't explain how to do that, or even suggest it. How many COBOL programmers know about hexadecimal display? What is left of your request to put into the messages manual? Essentially everything. When did they do this? I don't know; all that I know is that they used to do so and that you claim that they no longer do. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
In [EMAIL PROTECTED], on 07/02/2005 at 12:05 AM, Joe Zitzelberger [EMAIL PROTECTED] said: That was viewing it with SDSF. Then why did you write ISPF? There is an old joke Compiler error messagtes are not supposed to be jokes. If a person writing Cobol is not conversant with Cobol then the best thing that can happen to them is a Read the LRM message. No; such messages are singularly unhhelpful. It *might* be helpful to direct them to a specific section of the LRM. Compilers are not chain-saws, Well, they're not supposed to be, but when you have a large number of opaque message that the authors incorrectly believe to be self documenting, they might as well be. Using your theory above, one would think that a programmer moving from an APOS to a non-APOS shop would be paralyzed with fear at the sight of characters? You obviously don't un derstand my theory. You have repeatedly asked for things that are already provided by the current message. ROTF.LMAO! Not even close. I have asked for, e.g., a quote in hex of the offending text, an explanation of what SI/SO are all about, and those are *not* in the message. The message does provide context for the programmer, You seem to have a strange idea of what context is; none of my dictionaries define it as the column number of the character in error. There is no rational way to read context for a programmer who doesn't know about DBCS as refering to a column number. The listing already provides the 'bad text' with the message. Which part of in hexadecimal don't you understand? If you believe it is unnecessary, say so, but to claim that it is there is dishonest. The LRM provides both of these What is at issue is what is in the error message, not what is in the LRM. Either their technical writers are as dumb as the average Cobol programmer or there truly are 'self-evident' message in the problem space of computer programming. Or it will be fixed the first time someone submits an RCF. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
---SNIP- Or it will be fixed the first time someone submits an RCF. Seymour, There is MC to submits A RCF for :) 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: Another OS/390 to z/OS 1.4 migration question (COBOL)
Joe Zitzelberger wrote: On Jul 1, 2005, at 9:26 AM, Ed Gould wrote: Trying to find replacements is extremely hard. Almost all the schools are not teaching cobol anymore . The company just outsourced its entire IT department to IBM. Maybe they can straighten the mess out. Its by all means not *ALL* a programmer issue its management as well. To give you a brief flavor there were two VP's screaming at each other in the middle of a work area. Thats how bad it is. You might want to consider getting an experienced programmer with no Cobol and locking them in a cube for a week with the Programmers Guide and Programmers Reference. Or you might want to consider training them! Oh, nah, silly idea. Costs money. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 soap box Spending Money for education? What a novel idea! We have all the trained people we'll ever want on the market, and if we wait long enough we might get them even cheaper than people from off shore locations /soap Steve Comstock said the following on 07/03/2005 05:11 PM: | | Or you might want to consider training them! | | Oh, nah, silly idea. Costs money. | | Kind regards, | | -Steve Comstock | | -- | For IBM-MAIN subscribe / signoff / archive access instructions, | send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO | Search the archives at http://bama.ua.edu/archives/ibm-main.html | - -- ~ With kind Regards|\ _,,,---,,_ ~ZZZzz /,`.-'`'-. ;-;;, ~ Volker Bandke |,4- ) )-,_. ,\ ( `'-' ~ (BSP GmbH)'---''(_/--' `-'\_) ~ I'm DESPONDENT ... I hope there's something DEEP-FRIED under this ~ miniature DOMED STADIUM ... ~ (Another Wisdom from my fortune cookie jar) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCyB9CHm2sbKEAXTARApD9AJ0QGOM+SrQvnt56swEYaXQodCM6uACgu7Iq gOs6Xh/mQhEezEpvknU3fO0= =02Wy -END PGP SIGNATURE- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jul 1, 2005, at 12:43 AM, Joe Zitzelberger wrote: SNIP Ideally you would find them working in the industry for at least 3-5 years after successfully completing formal training in computer science at some university, technical school, military, et al. Failing that, some partial completion of some of the listed conditions might qualify them for an entry level gig. Where do you get yours? I notice you call them cobol programmers. This always suggests a lack of any kind of training to me -- most (all) formal training program at university or technical schools, or even corporate internships, will include more than one programming language, along with some theory. I've heard tale of shops where after a few years of sweeping the computer room floor you are handed a compiler manual and promoted to programmer. One gets what one pays for... The last company I worked for had programmers on the east coast as well as ones from the midwest. As I was told this all you need is a warm body and some history of programming. The job market (I was told) for cobol programmers is pretty much first come first serve. At one place they almost SHANG-HI you off the street. So companies get pretty much the left overs. So if your Cobol programmers are so lazy and stupid, why do you keep them? Why not send the lot packing and give their collective salaries to a smaller number of hard-working and competent programmers that will not need to be told where to insert code? Trying to find replacements is extremely hard. Almost all the schools are not teaching cobol anymore . The company just outsourced its entire IT department to IBM. Maybe they can straighten the mess out. Its by all means not *ALL* a programmer issue its management as well. To give you a brief flavor there were two VP's screaming at each other in the middle of a work area. Thats how bad it is. 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: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jul 1, 2005, at 7:51 AM, Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 06/30/2005 at 10:55 PM, Joe Zitzelberger [EMAIL PROTECTED] said: TSO/ISPF is about as least common denominator as you can get. The Sun rises in the East. ISPF is not the issue. The issue is the contents of the listing file. Which, by the way, is normally a SYSOUT file viewed through SDSF. Viewing output datasets in SDSF can be done in four ways. There is the SE command that opens the spool dataset using ISPF Edit. There is the SB command that opens the spool dataset using ISPF Browse. There is the S command that formats the dataset for a line printer and browses it in an SDSF specific, but ISPF work-alike browser. And there is the V command that formats the dataset for a page printer and browses it in the same SDSF specific, ISPF work-alike browser. For purposes of online viewing V, S and SB are identical in function. There is one quirk that is germane to the discussion -- in ISPF browse the command to show hex is hex on -- in the S and V browse the command is set hex on. Otherwise, when used to browse a listing they are identical. The only visual indication of difference between the two browsers is some slightly different stuff in the first two header rows -- one says something like ISPF Browse and the other doesn't. The ISPF Edit, SE, makes the data editable, though not save-able. The various ISPF edit commands like CREATE, REPLACE, CUT, EXCLUDE, etc are available as well as the users custom edit macros, like the ever-present INCLUDE (props to D.Lowe). Anyway, those are the minimum you will have with TSO or ISPF. There is no circumstance where a programmer is unable to easily see the hex values of any byte in the listing. (FYI -- If you can't get these functions working with SDSF, if you get an EDIT NOT AVAILABLE message, try starting SDSF via ISPEXEC instead of TSO) Here is a brief example of the problem, viewed through the eyes of ISPF, with a spool dataset listing: That's not something that a COBOL programmer would be likely to do; he's either direct it to DASD or view it with SDSF. Further, if he didn't know about DBCS, he'd have no idea what SI and SO were and wouldn't know to use a hexadecimal editor. That was viewing it with SDSF. The shift is included in the literal in the listing and the messages are shown following the offending line and the column is clearly described. I don't what the column clearly described, and want the error and programmer response clearly described. There is an old joke -- A man walks in to a doctors office and twists his arms above his head. He says Doc, it hurts when I go like this. The doctor says So don't go like that. Not very funny -- it really depends on delivery. Syntax errors are like this -- an END-IF without an IF, an unmatched quote, unmatched apostrophe, unbalanced parenthesis or unbalanced shift. The compiler is simply saying that your source didn't match it's syntax -- when your source does match it's syntax, the compiler will stop complaining. The solution is in the message: don't go like that. The questioner was not necessarily conversant with Cobol at all. Many people writing COBOL (not Cobol) are not conversant with COBOL; they're part of the target audience. Pronounceable acronyms tend to become worded after many years of common use. I will cite the Merriam-Webster dictionary to support the word-like usage. See also radar, laser and scuba. If a person writing Cobol is not conversant with Cobol then the best thing that can happen to them is a Read the LRM message. It is not unusual, or unreasonable, to expect people who are using any tool to briefly scan the instructions first. Compilers are not chain-saws, but the do offer the opportunity to injure ones foot in the figurative sense. I'm not sure if non-Cobol programmers would qualify as a representative sample of people who should understand Cobol compiler messages. If they do, then all messages should be annotated -- programmer response: learn Cobol. That would be singularly unhelpful, which is no surprise. Programmers, including COBOL programmers, typically learn only the parts of the language that they use. They are often unprepared for error messages referring to language features that they did not intend to use or don't even know about. That is what IBM makes, freely available and electronically searchable, the Language Reference Manual and Programmers Guide. One can become so incapacitated trying to remember every little detail of everything that they completely miss the big picture. The old forest for the trees syndrome. SHIFT-IN and SHIFT-OUT are special registers that are well described in the above guides. One doesn't need to know anything about eastern character sets or DBCS to know that they operate in pairs -- just like QUOTE, APOS and parens.
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 29, 2005, at 1:37 PM, Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 06/29/2005 at 09:03 AM, Joe Zitzelberger [EMAIL PROTECTED] said: ISPF will offer a note line to the effect of nondisplayable data, Water is wet. That doesn't help if you have no water. TSO/ISPF is about as least common denominator as you can get. It is editor state-of-the-art, circa 1980. As such, it offer the minimum functionality to display listings. And it is what IBM will use to display those listings if you use their development tools. Again, this only applies if you view your listing as a DASD file. Not if the compiler translates out nondisplayable data. The compiler doesn't translate out nondisplayable. I'm not aware if they ever did, but I don't recall it going back to VS Cobol II. Here is a brief example of the problem, viewed through the eyes of ISPF, with a spool dataset listing: move 'hex literal SI is here' to dummy-var 44499A84788A498A89894EC4048A4889874A948A99A4 444 00046550D857039359130290F09208595D036080 000 PS0156-E A shift-in was found in column 33 without a matching shift- out in a nonnumeric or national literal. The literal was processed as written move 'hex literal SO is here' to dummy-var 44499A84788A498A89894ED4048A4889874A948A99A4 444 00046550D857039359130260E09208595D036080 000 0157-E A shift-out was found in column 33 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written The shift is included in the literal in the listing and the messages are shown following the offending line and the column is clearly described. Would you like the compiler to bring you a cup of coffee while you consider the problem as well? What more could possibly be said in a message manual? That is what the translator, with the given options would insert. One of those blank-looking columns in the alphanumeric literal is going to be the problem. Again, the issue is what the compiler puts in the file, not what was in its input. The external translator input has always been viewable in the Cobol compiler listing. Somehow, some people think that these messages are not self- documenting and completely obvious given the context in which they are used. That's because they aren't, as demonstrated by empirical data; the OP did *not* understand the message. Somehow people believe that just because they understand a message based on external knowledge that the target audience must understand it. The questioner was not necessarily conversant with Cobol at all. My understanding from the post was that he was a sysprog. That would indicate maybe some assembler, some PL/I, maybe some C...but Cobol? I'm not sure who asked him the original question -- a university student in the first week of Cobol 101? A non-Cobol programmer installing a vendor product using vendor supplied compile JCL? There are possibilities where non Cobol programmers could be running compiles. If the audience included people that were conversant in CICS development and in Cobol development, I would expect them to understand the message in context, even without DBCS knowledge. There are a number of 'names' for chars (NUL, NAK, ACK, LF, BS, CR, etc) that do not mean much to a Cobol programmer in a z/OS environment, but an unexpected x'??' is pretty clear. You want to know whether a message is self documenting? Put together a testing laboratory and expose a representative sample of real users to it. If a significant number don't understand it, then it is not self documenting, no matter how clear it is to you. I'm not sure if non-Cobol programmers would qualify as a representative sample of people who should understand Cobol compiler messages. If they do, then all messages should be annotated -- programmer response: learn Cobol. Again, I would ask, how much more documentation would you put on it? The message points you to the exact byte in error and says this looks funny to me, but I'll trust you want it there and accept it as written. What could you say about it? Read the LRM seems like the only polite thing that could be written. And you still haven't said whether the compiler actually retains the SI and SO in the listing file. I've never doubted it, but I tested it for your benefit. It does. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 30, 2005, at 9:55 PM, Joe Zitzelberger wrote: -SNIP- I'm not sure if non-Cobol programmers would qualify as a representative sample of people who should understand Cobol compiler messages. If they do, then all messages should be annotated -- programmer response: learn Cobol. Again, I would ask, how much more documentation would you put on it? The message points you to the exact byte in error and says this looks funny to me, but I'll trust you want it there and accept it as written. What could you say about it? Read the LRM seems like the only polite thing that could be written. I was going to sit and watch this progress to the obvious (to me) completion. I am not sure where you find your cobol programmers Joe, but in the midwest they tend to be (not all) lazy. Some of them couldn't code if they were handed the code to insert . I am not proficient in cobol and let me tell you I had a real (now forgotten) cobol error message and it really didn't help that a cobol programmer was asking me what the message meant. I did not have a clue. I opened a ETR with all the information including snippets of code and all the information that seemed relivent. I got a call back asking to fax the listing (this was a decent size cobol program ). ABout 2 days later (reasonable amount of time) I got an update to the ETR saying the program had been written in HP cobol (IIRC) and it was too big (NOT memory size) for the compiler. I wish I had kept a record of the error message now. The error message was at best vague. I asked that the message be documented better and was refused saying that the messages are self explanatory. I countered with reason and they basically told me to get lost. I had to go back to the programmer and ask him to break up the program he wanted to know how I had figured it out as the message was vague and ambigious I just said because IBM said so. I felt like a jerk because IBM refused to explain themselves. This (to me was not a duty manager issue) I have been complaining to deaf ears to this day about the lack of error messages and codes manual for cobol. The lack of a M C for cobol is but a long list of issues that IBM has lost it to the pc weenies. I seriously think IBM has lost it on several fronts. 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: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 30, 2005, at 11:30 PM, Ed Gould wrote: On Jun 30, 2005, at 9:55 PM, Joe Zitzelberger wrote: -SNIP- I'm not sure if non-Cobol programmers would qualify as a representative sample of people who should understand Cobol compiler messages. If they do, then all messages should be annotated -- programmer response: learn Cobol. Again, I would ask, how much more documentation would you put on it? The message points you to the exact byte in error and says this looks funny to me, but I'll trust you want it there and accept it as written. What could you say about it? Read the LRM seems like the only polite thing that could be written. I was going to sit and watch this progress to the obvious (to me) completion. I am not sure where you find your cobol programmers Joe, but in the midwest they tend to be (not all) lazy. Some of them couldn't code if they were handed the code to insert . Ideally you would find them working in the industry for at least 3-5 years after successfully completing formal training in computer science at some university, technical school, military, et al. Failing that, some partial completion of some of the listed conditions might qualify them for an entry level gig. Where do you get yours? I notice you call them cobol programmers. This always suggests a lack of any kind of training to me -- most (all) formal training program at university or technical schools, or even corporate internships, will include more than one programming language, along with some theory. I've heard tale of shops where after a few years of sweeping the computer room floor you are handed a compiler manual and promoted to programmer. One gets what one pays for... So if your Cobol programmers are so lazy and stupid, why do you keep them? Why not send the lot packing and give their collective salaries to a smaller number of hard-working and competent programmers that will not need to be told where to insert code? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 29, 2005, at 1:51 PM, Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 06/28/2005 at 09:27 PM, Bill Klein [EMAIL PROTECTED] said: I don't understand your comment. Because you ignored part[1] of it and are are assuming that what appears in the listing is identical to what appears in the source code. That certainly didn't use to be true, and so far nobody has been willing to state that it has changed. That is because it doesn't change. The compiler displays the source in the listing exactly as it appeared upon input. As previously indicated the FLAG(I,I) option became the default at the same time as DBCS. As previously indicated, that is irrelevant. A check engine light is irrelevant if it does not appear on an auto dashboard. How can the exact byte location of the error, with surrounding source lines for context, be irrelevant to resolving the error? Therefore, the compiler error message WILL appear in the listing IMMEDIATELY after the line inserted by the translator (indicating the column in that line with the problem). What good does that do when the message lacks the necessary data to diagnose the problem and is unintelligible to the target audience? The message includes the row and column of the offending byte. As well as a description of its offense. In what possible way could you consider that 'unintelligible'? If a CICS application programmer can't recognize a translator inserted line with Move alphanumeric literal to DFH field as being inserted by the translator Straw dummy. The CICS programmer can recognize it; what he can't do is to guess what nondisplayable data are in the text. Why doesn't he/she look at what non-displayable data are in the text? The command string Set Hex On comes to mind. and/or if that same programmer can't recognize that the column that the message is pointing to is within an alphanumeric literal, Another straw dummy. then NO messages and codes manual is ever going to help that programmer (IMHO) A combination of a messages manual and a better message would. Starting with displaying the message text in hexadecimal, explaining what SI and SO are and giving their hexadecimal values. They gave you the row and column. They gave you the figurative constant name. Turning hex on will give you the value. What is left of your request to put into the messages manual? [1] Have they stopped translating out nondisplayable characters? When did they do this? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
In [EMAIL PROTECTED], on 06/29/2005 at 09:03 AM, Joe Zitzelberger [EMAIL PROTECTED] said: ISPF will offer a note line to the effect of nondisplayable data, Water is wet. That doesn't help if you have no water. Again, this only applies if you view your listing as a DASD file. Not if the compiler translates out nondisplayable data. That is what the translator, with the given options would insert. One of those blank-looking columns in the alphanumeric literal is going to be the problem. Again, the issue is what the compiler puts in the file, not what was in its input. This is the problem we have been discussing. No, it is only half of the problem. Somehow, some people think that these messages are not self- documenting and completely obvious given the context in which they are used. That's because they aren't, as demonstrated by empirical data; the OP did *not* understand the message. Somehow people believe that just because they understand a message based on external knowledge that the target audience must understand it. You want to know whether a message is self documenting? Put together a testing laboratory and expose a representative sample of real users to it. If a significant number don't understand it, then it is not self documenting, no matter how clear it is to you. And you still haven't said whether the compiler actually retains the SI and SO in the listing file. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 24, 2005, at 8:42 AM, Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 06/23/2005 at 01:33 PM, Bill Klein [EMAIL PROTECTED] said: With FLAG(I,I) which became the default at the same time as DBCS, the message *does* appear exactly AFTER the line (inserted by the preprocessor) which follows the originally coded line. As the mesage also tells the column where the problem exists, it should be pretty obvious where the problem was. (Again - or at least it would be to me) Okay, so you look at column 50 in the listing and you see a blank? Now what? It would help if the message included the offending literal text, in hexadecimal, and explained SI and SO for the benefit of those who have no reason to understand DBCS. If I didn't know what DBCS was I would have found the message to be totally opaque, and as is I still wouldn't have known what the offending data were. While column 50 might look blank iff you are using a printed listing (a rarity in the days of syntax highlighting editors and a waste of trees) -- the surrounding columns would have something like: Move 'a 0d 2 ic$k34 d pd e,x d' to DFHEI1234 That should be enough for anyone to realize it is a translator problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
... And why were all those pages left blank intentionally ? ... We used to call that “The IBM oxymoron”. A page stating it's blank, by definition cannot be blank. -teD (The secret to success is sincerity. If you can fake that, you've got it made!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
And why were all those pages left blank intentionally ? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Joe Zitzelberger Sent: Saturday, June 25, 2005 11:11 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another OS/390 to z/OS 1.4 migration question (COBOL) On Jun 24, 2005, at 11:15 PM, Ed Gould wrote: On Jun 24, 2005, at 9:53 PM, Joe Zitzelberger wrote: On Jun 24, 2005, at 5:13 PM, Ed Gould wrote: On Jun 24, 2005, at 12:23 PM, Bill Klein wrote: --SNIP--- NOTE WELL: Although this topic comes up occasionally in IBM-MAIN, there really are VERY FEW questions in either comp.lang.cobol or TEK-TIPS about what does the following IBM COBOL compiler message mean. This does (to me) confirm the IBM belief that MOST of the messages *are* self-documenting. Even for the message in question, it is my belief that MOST of the time that it is issued is because someone using DBCS within alphanumeric literals have mis-coded it. This along with the fact that the currently supported CICS translators with the recommended translator options do NOT cause the problem, makes it hard for me to blame the compiler message or documentation. I am not sure I agree with you. *MOST* programmers I have had exposure to don't have access to usenet. Their only lines of defense is ask someone else or call the help desk. I still want to know who to call when they say call your systems programmer. Ed Twenty years ago that might have flown. But since the mid-1990s that just doesn't fly. Everyone and their grandmother has 'access' to usenet. While only about 95% of them will have it in their home, the rest are just a hop-skip-and-jump from a public library or a big box superstore complete with free internet access. They may not use it, but access is universally available in the developed world and pretty much available in the undeveloped world as well. Joe, At the last place I worked USENET access was blocked PERIOD.. Ed It's blocked where I work as well -- that doesn't stop half the programmers from using their PDAs or cell phones to access it when they need it... -- For IBM-MAIN subscribe / signoff / archive access instructions, 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: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 23, 2005, at 12:09 AM, Thomas Conley wrote: Not at all. Just because you find a shift-in in your source doesn't mean the error message is at fault. If you look at your listing and actually see a shift in there, then you might want to complain about the preprocessor that placed it there. But that would be the preprocessors fault, not the message -- it means exactly what it says. If you will pardon the pun, this sound like a perfect example of 'shooting the messenger' instead of addressing the root cause. Joe, You are wrong here. Imagine a shop that has used COBOL for decades, and can't even spell DBCS. All of a sudden this message pops up after a compiler upgrade. The programmer asks What's a shift-in? The systems programmer says BTF outta me. Let's get the message manual. Oops, no manual, now what? Open a PMR only to be told by COBOL Level 2 what an idiot you are.. My shop can't spell DBCS. And I've never, ever, ever, used DBCS. But I still know about the two figurative constants SHIFT-IN and SHIFT-OUT. Shift-In and shift-out are fully documented in the programmer reference and programmer guide. Two manuals that any programmer should be familiar with. And a look at the listing would clearly show a SI/SO actually in the source. And the location of the SI/SO is documented in the message to be within a preprocessor command. The problem is not with the compiler or the shift message -- it is with the preprocessor. Until that is fixed the old garbage-in/ garbage-out. When one receives garbage upon output, it is a good assumption that you will find garbage in the input. Your assumption that this message tells the whole story is absurd. Every IBM message is supposed to have a response documented, like this: Programmer response: If using DBCS support, be sure that your DBCS character stream contains proper shift-in shift-out pairs. If you are not using DBCS, be sure that you specify the NODBCS in your compile. The message was fully valid, improperly started or terminated literals are improperly started or terminated literals. The message clearly documented that. Why do you feel the need for a manual that says: Programmer response: Always use DBCS literal delimiters in pairs. Problem solved. Expecting the user to know every option and feature of the COBOL compiler, especially those features and options that they're not even using, is ridiculous. That's why every error message generated by an IBM product is supposed to be fully documented with appropriate Response sections. There is no need for the programmer to know how DBCS works, only that one of the delimiters was plugged into their code by the preprocessor. From there, the issue is not DBCS at all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
In [EMAIL PROTECTED], on 06/23/2005 at 11:31 AM, Tom Ross [EMAIL PROTECTED] said: I assure you that the compiler writers find the messages totally informative. For most of them that is true. Well, yes, but the compiler writers should not be the target audience. I assure you that programmers who are not compiler writers do not find the messages totally informative. Our challenge was what do you add to that in a messages manual? Talk to the PL/I folks; their messages are more helpful than yours, but they still manage to find useful things to say in their messages manuals. All you can say is See the LRM for how to code that statement. No, that is not all that you can say, at least not for the messages that I have seen. but 90% of entries would say See the LRM Then you need to put your tech writers in touch with people actually trying to use the compiler and ask them what they understand from the messages. Don't be surprised if different programmers have different interpretations. Anyway, the DBCS messages look like a good candidate for needing a messages manual, or at least a message update. Also a good candidate for revising the message contents. Back in the COBOL (E) days there was an excuse for skimpy error messages; with current DASD costs there is no reason not to have, e.g., multi-level messages, more variables plugged into the message text. There was never an excuse to claim that messages were self documenting; it wasn't true in OS/360 and it isn't true now. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
In [EMAIL PROTECTED], on 06/23/2005 at 07:23 PM, Joe Zitzelberger [EMAIL PROTECTED] said: While the preprocessors usually do a decent job, blind faith in their abilities is excessive. There are many cases where they can produce errors in a compile. How will having more documentation about a perfectly valid mangled literal help one diagnose a preprocessor problem? By explaining the nature of the munging? By suggesting[1] that the programmer examine the literal in hex? It won't. Sure it will; see above. In all contexts, this message means you have a screwed up DBCS literal in your source code. I don't understand CJK languages. Why would a reasonable author expect me to know what DBCS is in the first place, much less what SI and SO are. None of those are terms used by COBOL programmers not involved in Asian languages. and that is exactly what the self-describing message says. There was no self-describing message. There was an opaque message that was meaningless to its target audience. Even had there been an explanation it would have been appropriate to fix the message contents. Now, admittedly I understood the message, but my background is broader than that of most programmers, and even I would have been frustrated by the absence of the data in error from the message. It would have been better had the message contained the hexadecimal code points for SI, SO and the literal text in error. To get any sort of a constructive fix a programmer will have to quit trying to lay blame on the compiler and address the root cause -- the preprocessor. Finger pointing. The message itself is broken, which makes it more difficult than it needs to be for the programmer to identify the preprocessor as the problem. The message is an issue in contexts where there is no preprocessor. No amount of message manuals from IBM will ever help them in this effort Wrong. A manual that suggested looking at the literal in hexadecimal and suggested that the literal might have come from a preprocessor would have saved a lot of time in the incident under discussion. and requests for such are only trying to treat the symptom while ignoring the real problem. The message is the real problem; the preprocessor is only one of the avenues for hitting it. Note: I have frequently defended IBM error messages as adequate and told people to RTFM when they couldn't understand them, but in this case the message is inadequate and there is no FM. [1] Raising the question of why the error message didn't include a brief section of the literal in hex. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 24, 2005, at 12:23 PM, Bill Klein wrote: --SNIP--- NOTE WELL: Although this topic comes up occasionally in IBM-MAIN, there really are VERY FEW questions in either comp.lang.cobol or TEK-TIPS about what does the following IBM COBOL compiler message mean. This does (to me) confirm the IBM belief that MOST of the messages *are* self-documenting. Even for the message in question, it is my belief that MOST of the time that it is issued is because someone using DBCS within alphanumeric literals have mis-coded it. This along with the fact that the currently supported CICS translators with the recommended translator options do NOT cause the problem, makes it hard for me to blame the compiler message or documentation. I am not sure I agree with you. *MOST* programmers I have had exposure to don't have access to usenet. Their only lines of defense is ask someone else or call the help desk. I still want to know who to call when they say call your systems programmer. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
From: Bill Klein If messages start appearing after a migration of compilers, then SOMEONE (application programmer or systems programmer) SHOULD have the sense to check in the Migration Guide. Furthermore, IMHO, anyone (systems programmer) who does a migration of compilers and does NOT look at what compiler options are DOCUMENTED as changing and figuring out what implications this has for their shop, isn't doing their job. Mmmm - I don't think I've ever been in a Cobol debate, and I sure as hell wouldn't challenge Bill, but this needs comment. Are you aware of how many bloody migration guides are lined up for a decent upgrade ???. After the install I generally do any IVPs, but this sort of problem is unlikely to be picked up till we get to Devl. Even if it was in the mig guide for Cobol (or would that be LE, or CICS, or Endeavor as it builds all the JCL for compiles/pre-precessors, or ...), it would probably be missed by the likes of me. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
- Original Message - From: Bill Klein [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Thursday, June 23, 2005 8:45 AM Subject: Fw: Another OS/390 to z/OS 1.4 migration question (COBOL) What is not self-describing about these is why they suddenly started appearing when the programmer hadn't changed any of his code, that's what! If messages start appearing after a migration of compilers, then SOMEONE (application programmer or systems programmer) SHOULD have the sense to check in the Migration Guide. Furthermore, IMHO, anyone (systems programmer) who does a migration of compilers and does NOT look at what compiler options are DOCUMENTED as changing and figuring out what implications this has for their shop, isn't doing their job. If the complain was (which is NOT true) that this isn't documented as a CHANGE in both the Migration and Installation manuals, then I would say - yes, there is a problem, but this one just isn't in that category. Bill, How about my case, where the failing program wasn't compiled until 6 months after the COBOL migration? HTF were we supposed to relate that failure to the bloody COBOL compiler upgrade? WTF do you guys have against IBM providing at least a programmer response field for each message? I just don't get why you guys continue to think that providing messages without a response field is acceptable. I bet you think that the BPX messages coming out of ISHELL are also self-documenting. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
Hum, there appears to be an apparent need/desire for this documentation, despite IBM's protestations. What I think would be interesting would be a Wikipedia like setup. That's where all these messages could be documented and then users could post their observations and helpful hints. Unfortunately, a Wikipedia is subject to defacing by kids, and others, who have nothing better to do. It also requires a hosting web site. Hum, I wonder if Marist would be interested? -- John McKown Senior Systems Programmer UICI Insurance Center 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: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Thu, 2005-06-23 at 09:16 -0400, Thomas Conley wrote: I bet you think that the BPX messages coming out of ISHELL are also self-documenting. Aw, c'mon Tom. There are some excellent decafs -- you should try one. The COBOL messages *are* (for the most) self-documenting. I can't offhand think of an instance when I couldn't figure out what one meant. If your programmers don't understand COBOL compiler messages then maybe they *should* consider another line of work -- or at least some remedial training. It is reasonable for the compiler developers to assume some level of competence on the user's part; COBOL isn't a 4GL after all. And it would be IMO a waste of time to have a tech writer produce something like: IGYOP3091-W Code from source code 1 to source code 2 can never be executed and was therefore discarded Explanation: The compiler detected that some of the program code could never be branched to. Rather than produce object code that would only take up space and never be executed, the compiler skipped the unexecutable program source code. In the message, source code 1 is the first of the source code that has been skipped, and source code 2 marks the end of code that was skipped. Programmer response: Examine the program listing and determine whether the code is intended to be executed. Source programs are line-numbered in the program listing, and the compiler error message includes the source program line number near which source code 1 can be found. Above notwithstanding, I recognize that it is MUCH easier to get a RCF accepted than an APAR, and if you *do* find a particular compiler error message wanting then you're tied to the maintenance QA process. So maybe what IBM needs is an error message server, accessible from all products, with a database that is easily updated. Changes to the database wouldn't require regression testing, and would have faster turnaround than you'd get from the standard publication schedule. Just thinking out loud. There are OA issues and other stuff to worry about, too. -- David Andrews A. Duda and Sons, Inc. [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 23, 2005, at 7:44 AM, Bill Klein wrote: Perryman, Brian [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] wgc.win2k.corp.tns i.com... SNIP snip What is not self-describing about these is why they suddenly started appearing when the programmer hadn't changed any of his code, that's what! If messages start appearing after a migration of compilers, then SOMEONE (application programmer or systems programmer) SHOULD have the sense to check in the Migration Guide. Furthermore, IMHO, anyone (systems programmer) who does a migration of compilers and does NOT look at what compiler options are DOCUMENTED as changing and figuring out what implications this has for their shop, isn't doing their job. ---SNIP Bill, While I agree with you (to a point). I have installed products I don't know squat about (example APL) with some of the options only an true engineer could understand. Asking IBM for help is at best iffy. The only sure thing is that you will be charged for any help. While APL is an extreme example there are other products that are similarly difficult. I will go for the easy one and that is LE the defaults (until recently ) were horrendous and how was one to know that they were bad ? After a lot of investigation by the experts IBM finally published a decent set of options. Now unless you went to SHARE you had no idea (and no way of knowing) that there were a better set of options around. I am not picking on LE per se (its an easy target) but how does one know about which options should be set and which should be left alone? Half the time the manuals are let than enlightening. Yes I know COBOL effects almost everyone and should be read closely but what do you do when the information is not enough and when you need to know any far reaching implications? SHARE is a partial answer but only if you know you are going to to be doing something 6 months in advance. COBOL at one time was a decent product and IMO has been sold out to the PFSKs. 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: Another OS/390 to z/OS 1.4 migration question (COBOL)
On 23 Jun 2005 07:16:02 -0700, in bit.listserv.ibm-main you wrote: On Thu, 2005-06-23 at 09:16 -0400, Thomas Conley wrote: I bet you think that the BPX messages coming out of ISHELL are also self-documenting. Aw, c'mon Tom. There are some excellent decafs -- you should try one. The COBOL messages *are* (for the most) self-documenting. I can't offhand think of an instance when I couldn't figure out what one meant. If your programmers don't understand COBOL compiler messages then maybe they *should* consider another line of work -- or at least some remedial training. Having programmed in COBOL since 1963 and having been a systems programmer who has submitted mods to the MVT tape, JES3 tape and CBT tape, I would have found the error message baffling. While someone should have caught the change in options (something I was normally paranoid about when going to a new release), the message is baffling if you aren't intentionally using shift-in and shift-out and this is the first time you've seen it. It becomes even more baffling to even an experienced COBOL programmer when the literal in question is generated by a preprocessor and the site doesn't intentionally use DCBS. Remember that the literal you see on the screen probably is not in hexadecimal so the shift-in may appear as a space. Normally the messages are fairly good but better help facilities for errors are needed. I suspect that the Integrated Development Environments provided by Microfocus and others on Unix and PC environments do a better job. It is reasonable for the compiler developers to assume some level of competence on the user's part; COBOL isn't a 4GL after all. And it would be IMO a waste of time to have a tech writer produce something like: IGYOP3091-W Code from source code 1 to source code 2 can never be executed and was therefore discarded Explanation: The compiler detected that some of the program code could never be branched to. Rather than produce object code that would only take up space and never be executed, the compiler skipped the unexecutable program source code. In the message, source code 1 is the first of the source code that has been skipped, and source code 2 marks the end of code that was skipped. Programmer response: Examine the program listing and determine whether the code is intended to be executed. Source programs are line-numbered in the program listing, and the compiler error message includes the source program line number near which source code 1 can be found. Above notwithstanding, I recognize that it is MUCH easier to get a RCF accepted than an APAR, and if you *do* find a particular compiler error message wanting then you're tied to the maintenance QA process. So maybe what IBM needs is an error message server, accessible from all products, with a database that is easily updated. Changes to the database wouldn't require regression testing, and would have faster turnaround than you'd get from the standard publication schedule. Just thinking out loud. There are OA issues and other stuff to worry about, too. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
SNIP -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Clark Morris While someone should have caught the change in options (something I was normally paranoid about when going to a new release) UNSNIP I feel that I'm being judged here, and in some previous posts, on shoddy workmanship. I should point out that this was on our test LPAR, where we specifically let developers and users loose to see what they can break. someone should have caught the change is exactly what this LPAR is there for. My original complaint was not that the developers compilation jobs suddenly don't work any more, but that I could not make sense of the message supposedly helping me to determine why. Brian - This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 23, 2005, at 9:18 AM, Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 06/22/2005 at 07:00 PM, Joe Zitzelberger [EMAIL PROTECTED] said: And you forgot to terminate or continue in accordance with the rules. No, *you* forgot that he was using the preprocessor. The data were not his in the first place. He simply trusted the IBM preprocessor to generate correct COBOL code. In context the message is clear as mud. While the preprocessors usually do a decent job, blind faith in their abilities is excessive. There are many cases where they can produce errors in a compile. How will having more documentation about a perfectly valid mangled literal help one diagnose a preprocessor problem? It won't. In all contexts, this message means you have a screwed up DBCS literal in your source code. It doesn't matter if it got there by a copy statement, a preprocessor or if the programmer hand-mangled it. It is still a screwed up DBCS literal and that is exactly what the self-describing message says. The programmer fix to such a problem is self-evident -- unmangle the DBCS literal. The proper use of DBCS literals is already fully documented in the Cobol language reference and programmers guide. If the preprocessor inserted the literal into your code, then the self evident fix is to tell the preprocessor to unmangle it. To get any sort of a constructive fix a programmer will have to quit trying to lay blame on the compiler and address the root cause -- the preprocessor. No amount of message manuals from IBM will ever help them in this effort and requests for such are only trying to treat the symptom while ignoring the real problem. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 23, 2005, at 12:43 PM, Perryman, Brian wrote: ---SNIP- I feel that I'm being judged here, and in some previous posts, on shoddy workmanship. I should point out that this was on our test LPAR, where we specifically let developers and users loose to see what they can break. someone should have caught the change is exactly what this LPAR is there for. My original complaint was not that the developers compilation jobs suddenly don't work any more, but that I could not make sense of the message supposedly helping me to determine why. Brian Brian as some messages used to say call your sysprog... did you have a fun conversation with yourself? 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: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 23, 2005, at 1:36 PM, Bill Klein wrote: So far, I haven't received any off-list or online replies to my pointing out my work-in-progress web page at: http://home.comcast.net/~wmklein/IBM/ErrMsg.htm Would this type of web-page be of use to those who can't figure out the COBOL compiler messages? Bill, Sell it at a profit and make it known to IBM:-) 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: Another OS/390 to z/OS 1.4 migration question (COBOL)
look here: http://www-1.ibm.com/support/docview.wss?uid=swg21163906 -Original Message- From: Perryman, Brian [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 7:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Another OS/390 to z/OS 1.4 migration question (COBOL) Hi folks Our developers are getting IGYPS0157-E and IGYPS0158E messages when they try and compile a CICS COBOL program on z/OS 1.4 in Enterprise Cobol of z/OS and OS/390 V3.2. I can't find these blasted messages documented anywhere!! Is there some convoluted format for decoding them? I suspect it's just a COBOL options member problem, but I need to see the message description. It only seems to happen when the CICS precompiler (CICS 4.1.0) is included first. The texts of the messages are: IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. IGYPS0158-E A nonnumeric or national literal containing double-byte characters was found which exceeded the maximum literal length or reached end of area B before terminating. A literal delimiter was placed at column 72 of line This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System intends this e-mail message, and any attachments, to be used only by the person(s) or entity to which it is addressed. This message may contain confidential and/or legally privileged information. If the reader is not the intended recipient of this message or an employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are prohibited from printing, copying, storing, disseminating or distributing this communication. If you received this communication in error, please delete it from your computer and notify the sender by reply e-mail. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
Brian, It has to do with the CICS Translator option you Are using, not COBOL option. I think the correct option is now COBOL3, but my mind is a little rusty on the topic. Dave Dave Jousma Principle Systems Programmer Fifth Third Bank Information Technology (Phone) 616-653-8429 (Fax) 616-653-8497 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Perryman, Brian Sent: Wednesday, June 22, 2005 7:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Another OS/390 to z/OS 1.4 migration question (COBOL) Hi folks Our developers are getting IGYPS0157-E and IGYPS0158E messages when they try and compile a CICS COBOL program on z/OS 1.4 in Enterprise Cobol of z/OS and OS/390 V3.2. This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
Thanks Dave, I'll probably try that too! - This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
Cobol decided that its internal messages were SO wonderful that they no longer needed a messages manual. Yes, really. I found this by opening a PMR with IBM. You can run the following program (Cobol 3.3) : //RUNIVP EXEC IGYWCLG,PARM.COBOL=RENT,REGION=0M, // PARM.LKED='LIST,XREF,LET,MAP' //GO.SYSOUT DD SYSOUT=* //*COBOL.SYSIN DD DISP=SHR,DSN=IGY.V3R3M0.SIGYSAMP(IGYIVP) //COBOL.SYSIN DD * IDENTIFICATION DIVISION. PROGRAM-ID. ERRMSG. /* And it will create a listing of all of the messages that cobol can do. However, I looked in my listing for the IGYPS messages and I couldn't find them. So I recommend you open a PMR with IBM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
Yeah, but unfortunately all this does is give a dump of the messages. No further information beyond what you get when the message happens for real. Some of those messages don't make a whole lot of sense - even if they're supposed to be written so well they don't need further explanation. -Original Message- From: John Mattson [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 22, 2005 10:41 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Another OS/390 to z/OS 1.4 migration question (COBOL) Cobol decided that its internal messages were SO wonderful that they no longer needed a messages manual. Yes, really. I found this by opening a PMR with IBM. You can run the following program (Cobol 3.3) : //RUNIVP EXEC IGYWCLG,PARM.COBOL=RENT,REGION=0M, // PARM.LKED='LIST,XREF,LET,MAP' //GO.SYSOUT DD SYSOUT=* //*COBOL.SYSIN DD DISP=SHR,DSN=IGY.V3R3M0.SIGYSAMP(IGYIVP) //COBOL.SYSIN DD * IDENTIFICATION DIVISION. PROGRAM-ID. ERRMSG. /* And it will create a listing of all of the messages that cobol can do. However, I looked in my listing for the IGYPS messages and I couldn't find them. So I recommend you open a PMR with IBM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html E-MAIL CONFIDENTIALITY USE NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. In addition, you are strictly prohibited from using, disseminating, distributing, copying, or storing this message and any 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
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
In many cases it's not a description of the message that's needed, it's what caused it and what your subsequent options for fixing it are that's needed. I can see that most of the messages from a compiler would indeed be self-documenting and quite rightly so, particularly since the reader is probably the programmer and therefore the one that caused the error situation to occur. Messages alerting of errors caused by external events are a different ball game however and should flipping well be documented! This e-mail message is for the sole use of the intended recipient(s)and may contain confidential and privileged information of Transaction NetworkServices. Any unauthorized review, use, disclosure or distribution isprohibited. If you are not the intended recipient, please contact thesender by reply e-mail and destroy all copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
- Original Message - From: Bill Klein [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, June 22, 2005 9:53 AM snip IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. IGYPS0158-E A nonnumeric or national literal containing double-byte characters was found which exceeded the maximum literal length or reached end of area B before terminating. A literal delimiter was placed at column 72 of line snip NOTE WELL: COBOL compiler messages (IGY) are *not* documented; they are self-documenting. If your application programmers can't figure out these specific messages, I would suggest additional training for them. If they don't know WHY they are getting the messages now (but not before), then I suggest you provide them references to the COBOL Migration Guide which does talk about such changes (NODBCS to DBCS). FYI, This self-documenting stuff is NOT IBM STANDARD!! IBM's official stance on messages is that ALL messages should be documented, with the appropriate Programmer and Operator response fields documented. I had this same argument with COBOL level 2 when I called in this problem. My exact words were HTF am I supposed to know that this error message was caused by you changing the default from NODBCS to DBCS? I did submit an RCF for this issue. Maybe someday the idiots in COBOL doc will fix it. Your premise that the users require additional training is patently absurd, as is the suggestion to provide a reference to the COBOL Migration Guide. HTF is anybody supposed to know that this error message was caused by something discussed in the COBOL Migration Guide? We had this same fight with ISPF messages ages ago, and now there's an ISPF messages manual because of it. COBOL should do the same. There, I feel better now. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
In [EMAIL PROTECTED], on 06/22/2005 at 12:41 PM, Perryman, Brian [EMAIL PROTECTED] said: I can't find these blasted messages documented anywhere!! According to IBM the COBOL messages are self explanatory. 1. Sure I'll respect you in the morning. 2. It's okay, Honey, I've had a vasectomy. 3. The check's in the mail. 4. The following messages are self explanatory. The first three are sometimes true. The smart money is against the last. This nonsense has been going on for decades. The ironic thing is that the PL/I messages *are* documented but, the last time that I looked, they were closer to self explanatory than the COBOL messages. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 22, 2005, at 5:34 PM, Ed Gould wrote: I will go for it hey its almost Friday. If you can't figure out what the message is saying open a PMR with the COBOL people tell them for the up teenth time that these messages are NOT self describing. Ed IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. A shift-out without a shift-in? Pretty obvious. IGYPS0158-E A nonnumeric or national literal containing double- byte characters was found which exceeded the maximum literal length or reached end of area B before terminating. A literal delimiter was placed at column 72 of line And you forgot to terminate or continue in accordance with the rules. What is not self describing about these? There are plenty of things to complain about with IBM's Cobol implementation -- but their error messages are pretty good. Perhaps even self-describing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
Joe Zitzelberger wrote: On Jun 22, 2005, at 5:34 PM, Ed Gould wrote: I will go for it hey its almost Friday. If you can't figure out what the message is saying open a PMR with the COBOL people tell them for the up teenth time that these messages are NOT self describing. Ed IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. A shift-out without a shift-in? Pretty obvious. Not if he was not using DBCS. No reason to expect this message. Apparently it was caused by the change if default compiler option settings, which does seem a little obscure, don't you think? IGYPS0158-E A nonnumeric or national literal containing double- byte characters was found which exceeded the maximum literal length or reached end of area B before terminating. A literal delimiter was placed at column 72 of line And you forgot to terminate or continue in accordance with the rules. What is not self describing about these? There are plenty of things to complain about with IBM's Cobol implementation -- but their error messages are pretty good. Perhaps even self-describing. Well, I'll be happy to concede they are pretty good most of the time. And I know they do work on improving them regularly. Kind regards, -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
On Jun 22, 2005, at 7:04 PM, Steve Comstock wrote: Joe Zitzelberger wrote: On Jun 22, 2005, at 5:34 PM, Ed Gould wrote: I will go for it hey its almost Friday. If you can't figure out what the message is saying open a PMR with the COBOL people tell them for the up teenth time that these messages are NOT self describing. Ed IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. A shift-out without a shift-in? Pretty obvious. Not if he was not using DBCS. No reason to expect this message. Apparently it was caused by the change if default compiler option settings, which does seem a little obscure, don't you think? Not at all. Just because you find a shift-in in your source doesn't mean the error message is at fault. If you look at your listing and actually see a shift in there, then you might want to complain about the preprocessor that placed it there. But that would be the preprocessors fault, not the message -- it means exactly what it says. If you will pardon the pun, this sound like a perfect example of 'shooting the messenger' instead of addressing the root cause. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another OS/390 to z/OS 1.4 migration question (COBOL)
- Original Message - From: Joe Zitzelberger [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main Sent: Wednesday, June 22, 2005 7:58 PM Subject: Re: Another OS/390 to z/OS 1.4 migration question (COBOL) On Jun 22, 2005, at 7:04 PM, Steve Comstock wrote: IGYPS0157-E A shift-out was found in column 50 without a matching shift-in in a nonnumeric or national literal. The literal was processed as written. A shift-out without a shift-in? Pretty obvious. Not if he was not using DBCS. No reason to expect this message. Apparently it was caused by the change if default compiler option settings, which does seem a little obscure, don't you think? Not at all. Just because you find a shift-in in your source doesn't mean the error message is at fault. If you look at your listing and actually see a shift in there, then you might want to complain about the preprocessor that placed it there. But that would be the preprocessors fault, not the message -- it means exactly what it says. If you will pardon the pun, this sound like a perfect example of 'shooting the messenger' instead of addressing the root cause. Joe, You are wrong here. Imagine a shop that has used COBOL for decades, and can't even spell DBCS. All of a sudden this message pops up after a compiler upgrade. The programmer asks What's a shift-in? The systems programmer says BTF outta me. Let's get the message manual. Oops, no manual, now what? Open a PMR only to be told by COBOL Level 2 what an idiot you are.. Your assumption that this message tells the whole story is absurd. Every IBM message is supposed to have a response documented, like this: Programmer response: If using DBCS support, be sure that your DBCS character stream contains proper shift-in shift-out pairs. If you are not using DBCS, be sure that you specify the NODBCS in your compile. Problem solved. Expecting the user to know every option and feature of the COBOL compiler, especially those features and options that they're not even using, is ridiculous. That's why every error message generated by an IBM product is supposed to be fully documented with appropriate Response sections. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
