/usr/lpp/java/common (was: IBM Knowledge Centre)
On Mon, 11 Jul 2016 08:31:55 +0800, Timothy Sipples wrote: >John McKown wrote: >>Am I being too "reactionary" ...? > >IBM doesn't think so: > >https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.hkcz100/kczos043.htm > >That link is specifically for z/OS 2.2. Refer to "KC-CI." > That page indirectly refers to a particular java version. Lately, IBM in a PTF I can't find, stabilized the path to java as a symlink from /usr/lpp/java/current (finally!) . Will that be maintained by any PTF that updates java, or will that, like the contents of /etc, be considered the prerogative of the site administrator?) Will Pubs do a sweep for mentions of particular java versions and substitute "current" as was done (mostly) when "dataset" was standardized as "data set"? (For consistency with the mode, it should be /usr/bin/java -- When in Rome do as the Romans do. Or perhaps pack your bags for India.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Knowledge Centre
On Sun, Jul 10, 2016 at 7:31 PM, Timothy Sippleswrote: > John McKown wrote: > >Am I being too "reactionary" in wanting to have my documentation > >on the same system as it is documenting? I.e. z/OS documentation > >on z/OS needing only access to z/OS without any other > >"specialized" software on a "desktop"? > > IBM doesn't think so: > > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.hkcz100/kczos043.htm > > That link is specifically for z/OS 2.2. Refer to "KC-CI." > > Many thanks. I've bookmarked that. -- "Pessimism is a admirable quality in an engineer. Pessimistic people check their work three times, because they're sure that something won't be right. Optimistic people check once, trust in Solis-de to keep the ship safe, then blow everyone up." "I think you're mistaking the word optimistic for inept." "They've got a similar ring to my ear." >From "Star Nomad" by Lindsay Buroker: Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Knowledge Centre
John McKown wrote: >Am I being too "reactionary" in wanting to have my documentation >on the same system as it is documenting? I.e. z/OS documentation >on z/OS needing only access to z/OS without any other >"specialized" software on a "desktop"? IBM doesn't think so: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.hkcz100/kczos043.htm That link is specifically for z/OS 2.2. Refer to "KC-CI." Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM sold TWS (IWS) ???
The following was posted on the 'Watching IBM' Facebook group page on July 6: Sent to Watching IBM: "Hi and thanks for your contributions in sharing information about IBM across countries. Please, as usual keep me anonymous. Today IBM Italia announced to employee of IBM Tivoli Workload Scheduler (formerly known as TWS) a sale of business of its product development and support to an indian company. 75 employees affected at the Rome Software lab will be transferred to another company with no choice, even if based in the same location (at least for now). Probably the first step to the dismission of the whole italian lab, founded in 1978, and according to Wikipedia is one of the largest software laboratory in the European Union." Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM sold TWS (IWS) ???
On 7/10/2016 3:34 AM, Juergen Kehr wrote: there were some rumours upcoming last week, that IBM solds TWS/IWS (Tivoli/IBM Workload Scheduler) to a Chinese company. Is this a (bad) joke or is there any truth behind these rumours? The seemingly never-ending staff reductions at IBM have forced them to seek partnerships with third parties to help maintain a "business as usual" posture with much of their software portfolio. These are not standard product re-marketing or sub-contracting arrangements, but rather intellectual property code-sharing agreements (called IPLAs) wherein a third party ISV takes over all development activities in exchange for a _huge_ percentage of the profits and any code they write is theirs to keep and use in their own products royalty free. Through these arrangements, IBM is able to reduce costs by disbanding their product development teams while continuing to "own" their product portfolio (which they technically still do on paper) despite having only minimal involvement. SDSF and OMEGAMON fall into this category as do numerous others, including at least one with the Tivoli brand. Such arrangements are generally not publicized and there is no legal requirement for IBM to do so. I don't know for sure what's going on with TWS, but I would not be the least bit surprised if it has fallen victim to one of these arrangements. I would, however, be quite surprised to learn a Chinese ISV is involved since none of the eleven IPLAs I am aware of involve Chinese companies. Another possibility is that IBM has simply moved development of TWS to China as they have done with z/OS BINDER, z/OSMF and numerous other products and components. In that case, there's likely no third-party ISV involvement at all (except possibly as sub-contractors) and nothing has been officially "sold." Please post additional details as you discover them... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error in a simple COBOL program
The SYSIN file in the OP's JCL was the source member for the compile. It has no relation to the program's execution other than the coincidence of the name SYSIN. Very likely, this caused some confusion. Obviously the OP is working on learning COBOL and JCL, and possibly many other things. Feel free to continue training, but you should consider the audience's level of understanding, not to mention the limitations of an email list for instruction. sas On 7/10/2016 14:15, Bill Woodger wrote: Sure. And there is a dataset with SYSIN data on it, which implies no human intervention. What do we do now, explode due to the contradiction? As I said, my guess is a non-Mainframe training example applied to the Mainframe. For a COBOL program on the Mainframe, I see no point in "interacting" in TSO. It doesn't happen in the wild. Why learn how to do it? Learning for learning, sure, but not as training for COBOL on a Mainframe. On Sunday, 10 July 2016 19:59:02 UTC+2, Dan Skomsky wrote: The original program includes the following statements: DISPLAY "TO END PROGRAM, ENTER 0.". DISPLAY "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.". The above statements are executed prior to "ACCEPT"ing every inputted amount. If the intent of this program was to receive input from a file, why would these statements be within the source? Why would they be repeatedly executed? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Error in a simple COBOL program
Ah. My carefully crafted scheme has failed. The SYSIN is the COBOL program, and I suppose it is "some considerable number of years" since it needed the step-name for that to work. Thanks Walt for pointing that out. OK, run it under TSO. Don't compile-and-go, just compile and link. Assign the input and output and run the program. Interact away. Enjoy, you'll never be doing it for real. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Error in a simple COBOL program
Sure. And there is a dataset with SYSIN data on it, which implies no human intervention. What do we do now, explode due to the contradiction? As I said, my guess is a non-Mainframe training example applied to the Mainframe. For a COBOL program on the Mainframe, I see no point in "interacting" in TSO. It doesn't happen in the wild. Why learn how to do it? Learning for learning, sure, but not as training for COBOL on a Mainframe. On Sunday, 10 July 2016 19:59:02 UTC+2, Dan Skomsky wrote: > The original program includes the following statements: > >DISPLAY "TO END PROGRAM, ENTER 0.". >DISPLAY "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.". > > The above statements are executed prior to "ACCEPT"ing every inputted amount. > If the intent of this program was to receive input from a file, why would > these statements be within the source? Why would they be repeatedly executed? > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CBT Tape Version 491 is now on www.cbttape.org
Hi Folks, I'm happy to say that CBT Version 491 is now available on www.cbttape.org. Of course, new Updates will be put on the Updates page from now on. As always, please download from the Updates Page first, if the file number you are looking for is there. In that way, you'll get the latest code for the file you're interested in. Use it all in good health (and with care). Sincerely,Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error in a simple COBOL program
The original program includes the following statements: DISPLAY "TO END PROGRAM, ENTER 0.". DISPLAY "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.". The above statements are executed prior to "ACCEPT"ing every inputted amount. If the intent of this program was to receive input from a file, why would these statements be within the source? Why would they be repeatedly executed? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Woodger Sent: Sunday, July 10, 2016 12:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Error in a simple COBOL program Here's one with the priming read, and a little trick for multiple ACCEPTs, because ACCEPT doesn't give "end of file". +1+2+3+4+5+6+7-- ID DIVISION. PROGRAM-ID. CALC1000. DATA DIVISION. FILE SECTION. WORKING-STORAGE SECTION. 01 INPUT-DATA. 05 FILLER. 88 END-OF-INTERACTIVE-SESSION VALUE HIGH-VALUES ZERO. 10 SALES-AMOUNTPIC 9(5)V99. 05 FILLER PIC X(73). 01 SALES-TAX PIC Z,ZZZ.99. PROCEDURE DIVISION. PERFORM PRIMING-READ PERFORM CALCULATE-ONE-SALES-TAX UNTIL END-OF-INTERACTIVE-SESSION GOBACK . CALCULATE-ONE-SALES-TAX. COMPUTE SALES-TAX ROUNDED= SALES-AMOUNT * 0.0785 DISPLAY SALES-AMOUNT " SALES TAX = " SALES-TAX PERFORM READ-DATA . PRIMING-READ. PERFORM READ-DATA . READ-DATA. MOVE HIGH-VALUES TO INPUT-DATA ACCEPT INPUT-DATA . The trick is through the knowledge that when ACCEPT operates and there is no remaining data, the target field (INPUT-DATA) remains unchanged. So set the target-field to a known value which cannot exist (logically) in the input, and you have an end-of-file test. In this case this is a catch-all for if the "user" gets the "I don't want any more" response wrong when using a dataset for input. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM sold TWS (IWS) ???
Technically, and the technical is important because it is a legal thing, Insider Trading is buying or selling based on knowledge that you have from within an organisation which is not yet public. OK, for the letter of the law, there is always a search-engine. Passing on the same inside information to others is a different thing. It is Insider Tipping. Both are very serious things, and are taken very seriously :-) Oh, and if you receive a Tip and you act on it you are doing Insider Trading. The TWS thing is most likely rumour. If you trade on rumour, you are probably safe from Insider Trading. And yes, they do check. They check very closely. On Sunday, 10 July 2016 18:47:02 UTC+2, Lizette Koehler wrote: > If this were public knowledge, I would think there would be news items on IBM > website or the Financial companies would be sending out notices of the sale > or potential sale. > > Since I am not seeing anything at this time, possibly false rumor. Or the > deal is not completed to the point where it can be commented on in the public. > > There are strict rules governing Stocks and Sales here in the USA. Nothing > can be shared (that would be insider trading) until the deal is done. > > Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Error in a simple COBOL program
Here's one with the priming read, and a little trick for multiple ACCEPTs, because ACCEPT doesn't give "end of file". +1+2+3+4+5+6+7-- ID DIVISION. PROGRAM-ID. CALC1000. DATA DIVISION. FILE SECTION. WORKING-STORAGE SECTION. 01 INPUT-DATA. 05 FILLER. 88 END-OF-INTERACTIVE-SESSION VALUE HIGH-VALUES ZERO. 10 SALES-AMOUNTPIC 9(5)V99. 05 FILLER PIC X(73). 01 SALES-TAX PIC Z,ZZZ.99. PROCEDURE DIVISION. PERFORM PRIMING-READ PERFORM CALCULATE-ONE-SALES-TAX UNTIL END-OF-INTERACTIVE-SESSION GOBACK . CALCULATE-ONE-SALES-TAX. COMPUTE SALES-TAX ROUNDED= SALES-AMOUNT * 0.0785 DISPLAY SALES-AMOUNT " SALES TAX = " SALES-TAX PERFORM READ-DATA . PRIMING-READ. PERFORM READ-DATA . READ-DATA. MOVE HIGH-VALUES TO INPUT-DATA ACCEPT INPUT-DATA . The trick is through the knowledge that when ACCEPT operates and there is no remaining data, the target field (INPUT-DATA) remains unchanged. So set the target-field to a known value which cannot exist (logically) in the input, and you have an end-of-file test. In this case this is a catch-all for if the "user" gets the "I don't want any more" response wrong when using a dataset for input. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Error in a simple COBOL program
On Sunday, 10 July 2016 15:56:12 UTC+2, Eric Mendelson wrote: > From tso allocate Sysin to your terminal and call the load module from tso > Then re-type the test data from the dataset. Thinking further, I have used ACCEPT to obtain a variable number of input cards. Just not tried it "interactively" with message to the user and such... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Error in a simple COBOL program
No. If you look at the SYSIN dataset that was used in the original JCL, it is has a DSN on it, a member of a PDS. The entire "session" responses can be included within that dataset without a problem. Or with a problem if the data does not conform to what the COBOL program "expects". It makes no difference whether the program is run in batch or TSO with that DSN, it does matter that the DSN is in the correct place. If the intention was to have an actual interactive session there would be no need to put data in that dataset (assumed) and attempt a compile-and-go with it. As an example of Mainframe COBOL for a beginner, it is a poor one, as I can count on the toes of one hand the number of times I've seen ACCEPT used in a loop on the Mainframe. It is a common type of example for a beginners' non-Mainframe COBOL course. It has been applied, by someone, to the Mainframe. Yes, you could use TSO, but to what advantage? To see the magnificent GUI that you can create? The options for input (which require that you code everything)? The immediate problem, as has been mentioned, is the override "misses" (or perhaps was not even attempted). The wider issue is that ACCEPT (and DISPLAY) in IBM COBOLs are very simple. Every other Vendor and their dog has Extended ACCEPT and DISPLAY - because they don't run on Mainframes, and you need something other than punched cards to communicate to the user with. Mainframe training for batch COBOL needs to be about file processing. Non-Mainframe training for COBOL needs to deal with the ACCEPT, DISPLAY (and maybe SCREEN SECTION) of the implementation of COBOL being trained for. The interest in this particular task is "you have to code it all yourself" which is, in fact., a somewhat more advanced task than the example. On Sunday, 10 July 2016 15:18:54 UTC+2, Keith Smith wrote: > What is missing is a method of making the program "know" that you want it > to get input from your screen. (or so it seems) > > If you want terminal input you need to use CICS or ISPF PANEL processing. > Or possibly execute this program from TSO. It has been a while but I know > of no way to tie a batch job to your terminal. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM sold TWS (IWS) ???
If this were public knowledge, I would think there would be news items on IBM website or the Financial companies would be sending out notices of the sale or potential sale. Since I am not seeing anything at this time, possibly false rumor. Or the deal is not completed to the point where it can be commented on in the public. There are strict rules governing Stocks and Sales here in the USA. Nothing can be shared (that would be insider trading) until the deal is done. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Juergen Kehr > Sent: Sunday, July 10, 2016 3:34 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: IBM sold TWS (IWS) ??? > > Hello, > > there were some rumours upcoming last week, that IBM solds TWS/IWS (Tivoli/IBM > Workload Scheduler) to a Chinese company. > Is this a (bad) joke or is there any truth behind these rumours? > > Does anybody know more about this message? > > Kind regards > Juergen > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HealthChecker rc 0401 in rexx check
Hello Peter, I write the length of the buffer before save to PQE and it is about 900 bytes. This explains why the four or fifth time I save into this area the program get this error. The docs per Rexx are not well documented as some of the services are supplied implicit like the one O used. BTW, no software errors was documented in erep... although there was abend involved. As per the problem, I changed the code to same to a dataset. Best, ITschak ITschak Mugzach Z/OS, ISV Products and Application Security & Risk Assessments Professional On Sun, Jul 10, 2016 at 5:00 PM, Itschak Mugzachwrote: > An home grown on. > בתאריך 10 ביול 2016 16:10, "Peter Relson" כתב: > > >A rexx check runs several iterations and failed with the above diagnostic >> >information. It is my understanding that 0401 is the reason code. If so, >> it >> >refers to implicit call to HZSQUERY that tried to retieve (or update) the >> >PQE area (which the rexx uses to pass information. Reason code 0401 mean: >> Not >> >all data was returned because the answer area is not big enough. Answer >> >area field HZSQUAAHTLEN /HZSQUAAH64TLEN indicates how much space is >> >currently required. >> >> I don't know that I'd necessarily agree with your understanding. You did >> not show the complete information that was received. >> The diagnostic information returned by a check is totally up to that >> individual check to document. It is true that 0401 with >> return code 4 is a possible return from HZSQUERY. It is also possible from >> any number of system services. >> >> What check are you referring to? >> >> >Any idea what cause the message? >> If the check invoked HZSQUERY and got this reason code, then it was >> because of exactly the reason that you quoted. >> The data that needed to be returned would not all fit in the provided >> area. >> >> FWIW, it would be very surprising to me for a REXX health check to use >> HZSQUERY. >> >> Peter Relson >> z/OS Core Technology Design >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HealthChecker rc 0401 in rexx check
An home grown on. בתאריך 10 ביול 2016 16:10, "Peter Relson"כתב: > >A rexx check runs several iterations and failed with the above diagnostic > >information. It is my understanding that 0401 is the reason code. If so, > it > >refers to implicit call to HZSQUERY that tried to retieve (or update) the > >PQE area (which the rexx uses to pass information. Reason code 0401 mean: > Not > >all data was returned because the answer area is not big enough. Answer > >area field HZSQUAAHTLEN /HZSQUAAH64TLEN indicates how much space is > >currently required. > > I don't know that I'd necessarily agree with your understanding. You did > not show the complete information that was received. > The diagnostic information returned by a check is totally up to that > individual check to document. It is true that 0401 with > return code 4 is a possible return from HZSQUERY. It is also possible from > any number of system services. > > What check are you referring to? > > >Any idea what cause the message? > If the check invoked HZSQUERY and got this reason code, then it was > because of exactly the reason that you quoted. > The data that needed to be returned would not all fit in the provided > area. > > FWIW, it would be very surprising to me for a REXX health check to use > HZSQUERY. > > Peter Relson > z/OS Core Technology Design > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error in a simple COBOL program
From tso allocate Sysin to your terminal and call the load module from tso Sent from my iPhone > On Jul 10, 2016, at 9:18 AM, Keith Smithwrote: > > What is missing is a method of making the program "know" that you want it > to get input from your screen. (or so it seems) > > If you want terminal input you need to use CICS or ISPF PANEL processing. > Or possibly execute this program from TSO. It has been a while but I know > of no way to tie a batch job to your terminal. > >> On Sat, Jul 9, 2016 at 2:40 AM, Cameron Seay wrote: >> >> I am experiencing a run time error with a simple COBOL program. It >> compiles fine. Here is the source code >> IDENTIFICATION DIVISION. >> * >> PROGRAM-ID. CALC1000. >> * >> ENVIRONMENT DIVISION. >> * >> INPUT-OUTPUT SECTION. >> * >> DATA DIVISION. >> * >> FILE SECTION. >> * >> WORKING-STORAGE SECTION. >> * >> 77 END-OF-SESSION-SWITCH PIC X VALUE "N". >> 77 SALES-AMOUNTPIC 9(5)V99. >> 77 SALES-TAX PIC Z,ZZZ.99. >> * >> PROCEDURE DIVISION. >> * >> 000-CALCULATE-SALES-TAX. >> * >> PERFORM 100-CALCULATE-ONE-SALES-TAX >> UNTIL END-OF-SESSION-SWITCH = "Y". >> DISPLAY "END OF SESSION.". >> STOP RUN. >> * >> 100-CALCULATE-ONE-SALES-TAX. >> * >> DISPLAY "---". >> DISPLAY "TO END PROGRAM, ENTER 0.". >> DISPLAY "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.". >> ACCEPT SALES-AMOUNT. >> IF SALES-AMOUNT = ZERO >> MOVE "Y" TO END-OF-SESSION-SWITCH >> ELSE >> COMPUTE SALES-TAX ROUNDED = >> SALES-AMOUNT * .0785 >> DISPLAY "SALES TAX = " SALES-TAX. >> >> Here is the JCL: >> >> ==MSG> your edit profile using the command RECOVERY ON. >> 000100 //CALC1000 JOB 1,'A. STUDENT',NOTIFY= >> 000110 //** >> 000120 //* COMPILE COBOL PROGRAM >> 000130 //** >> 000140 //STEP1 EXEC IGYWCLG >> 000150 //SYSINDD DSN=(CALC1001),DISP=SHR >> 000160 //COBOL.SYSLIB DD DSN=CEE.SCEESAMP,DISP=SHR >> 000170 //LKED.SYSLMOD DD DSN=(CALC1001),DISP=SHR >> >> Here is the error: >> >> --- >> TO END PROGRAM, ENTER 0. >> TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT. >> IEC130I SYSINDD STATEMENT MISSING >> *** >> >> IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN >> was uns >> uccessful. >> CEE3201S The system detected an operation exception (System Completion >> Code=0C1 >> ). >> From compile unit CALC1000 at entry point CALC1000 at compile >> unit off >> set +02DC at entry offset +02DC >> at address 1EE312DC. >> Abend 0C1000 hex occurred processing command 'CALL'. >> *** >> >> I can't find what is missing. >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Keith Smith > Engineer-Enterprise Sys Sr.-IT Capacity & Performance > Shaw Industries Inc. > Subsidiary of Berkshire Hathaway > 616 E Walnut Ave > Mail Drop 072-04 > Dalton, GA 30721 > Email: keith.sm...@shawinc.com Office: 706.532.3244 > > Please consider the environment before printing. > > -- > ** > Privileged and/or confidential information may be contained in this > message. If you are not the addressee indicated in this message (or are not > responsible for delivery of this message to that person) , you may not copy > or deliver this message to anyone. In such case, you should destroy this > message and notify the sender by reply e-mail. > If you or your employer do not consent to Internet e-mail for messages of > this kind, please advise the sender. > Shaw Industries does not provide or endorse any opinions, conclusions or > other information in this message that do not relate to the official > business of the company or its subsidiaries. > ** > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Error in a simple COBOL program
What is missing is a method of making the program "know" that you want it to get input from your screen. (or so it seems) If you want terminal input you need to use CICS or ISPF PANEL processing. Or possibly execute this program from TSO. It has been a while but I know of no way to tie a batch job to your terminal. On Sat, Jul 9, 2016 at 2:40 AM, Cameron Seaywrote: > I am experiencing a run time error with a simple COBOL program. It > compiles fine. Here is the source code > IDENTIFICATION DIVISION. > * >PROGRAM-ID. CALC1000. > * >ENVIRONMENT DIVISION. > * >INPUT-OUTPUT SECTION. > * >DATA DIVISION. > * >FILE SECTION. > * >WORKING-STORAGE SECTION. > * >77 END-OF-SESSION-SWITCH PIC X VALUE "N". >77 SALES-AMOUNTPIC 9(5)V99. >77 SALES-TAX PIC Z,ZZZ.99. > * >PROCEDURE DIVISION. > * >000-CALCULATE-SALES-TAX. > * >PERFORM 100-CALCULATE-ONE-SALES-TAX >UNTIL END-OF-SESSION-SWITCH = "Y". >DISPLAY "END OF SESSION.". >STOP RUN. > * >100-CALCULATE-ONE-SALES-TAX. > * >DISPLAY "---". >DISPLAY "TO END PROGRAM, ENTER 0.". >DISPLAY "TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT.". >ACCEPT SALES-AMOUNT. >IF SALES-AMOUNT = ZERO >MOVE "Y" TO END-OF-SESSION-SWITCH >ELSE >COMPUTE SALES-TAX ROUNDED = >SALES-AMOUNT * .0785 >DISPLAY "SALES TAX = " SALES-TAX. > > Here is the JCL: > > ==MSG> your edit profile using the command RECOVERY ON. > 000100 //CALC1000 JOB 1,'A. STUDENT',NOTIFY= > 000110 //** > 000120 //* COMPILE COBOL PROGRAM > 000130 //** > 000140 //STEP1 EXEC IGYWCLG > 000150 //SYSINDD DSN=(CALC1001),DISP=SHR > 000160 //COBOL.SYSLIB DD DSN=CEE.SCEESAMP,DISP=SHR > 000170 //LKED.SYSLMOD DD DSN=(CALC1001),DISP=SHR > > Here is the error: > > --- > TO END PROGRAM, ENTER 0. > TO CALCULATE SALES TAX, ENTER THE SALES AMOUNT. > IEC130I SYSINDD STATEMENT MISSING > *** > > IGZ0017S The open of DISPLAY or ACCEPT file with environment name SYSIN > was uns > uccessful. > CEE3201S The system detected an operation exception (System Completion > Code=0C1 > ). > From compile unit CALC1000 at entry point CALC1000 at compile > unit off > set +02DC at entry offset +02DC >at address 1EE312DC. > Abend 0C1000 hex occurred processing command 'CALL'. > *** > > I can't find what is missing. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Keith Smith Engineer-Enterprise Sys Sr.-IT Capacity & Performance Shaw Industries Inc. Subsidiary of Berkshire Hathaway 616 E Walnut Ave Mail Drop 072-04 Dalton, GA 30721 Email: keith.sm...@shawinc.com Office: 706.532.3244 Please consider the environment before printing. -- ** Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail. If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender. Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company or its subsidiaries. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HealthChecker rc 0401 in rexx check
>A rexx check runs several iterations and failed with the above diagnostic >information. It is my understanding that 0401 is the reason code. If so, it >refers to implicit call to HZSQUERY that tried to retieve (or update) the >PQE area (which the rexx uses to pass information. Reason code 0401 mean: Not >all data was returned because the answer area is not big enough. Answer >area field HZSQUAAHTLEN /HZSQUAAH64TLEN indicates how much space is >currently required. I don't know that I'd necessarily agree with your understanding. You did not show the complete information that was received. The diagnostic information returned by a check is totally up to that individual check to document. It is true that 0401 with return code 4 is a possible return from HZSQUERY. It is also possible from any number of system services. What check are you referring to? >Any idea what cause the message? If the check invoked HZSQUERY and got this reason code, then it was because of exactly the reason that you quoted. The data that needed to be returned would not all fit in the provided area. FWIW, it would be very surprising to me for a REXX health check to use HZSQUERY. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM sold TWS (IWS) ???
Hello, there were some rumours upcoming last week, that IBM solds TWS/IWS (Tivoli/IBM Workload Scheduler) to a Chinese company. Is this a (bad) joke or is there any truth behind these rumours? Does anybody know more about this message? Kind regards Juergen -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN