/usr/lpp/java/common (was: IBM Knowledge Centre)

2016-07-10 Thread Paul Gilmartin
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

2016-07-10 Thread John McKown
On Sun, Jul 10, 2016 at 7:31 PM, Timothy Sipples  wrote:

> 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

2016-07-10 Thread Timothy Sipples
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) ???

2016-07-10 Thread Dana Mitchell
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) ???

2016-07-10 Thread Ed Jaffe

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

2016-07-10 Thread Steve Smith
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

2016-07-10 Thread Bill Woodger
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

2016-07-10 Thread Bill Woodger
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

2016-07-10 Thread Sam Golob

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

2016-07-10 Thread Dan Skomsky
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) ???

2016-07-10 Thread Bill Woodger
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

2016-07-10 Thread Bill Woodger
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

2016-07-10 Thread Bill Woodger
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

2016-07-10 Thread Bill Woodger
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) ???

2016-07-10 Thread Lizette Koehler
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

2016-07-10 Thread Itschak Mugzach
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 Mugzach  wrote:

> 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

2016-07-10 Thread Itschak Mugzach
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

2016-07-10 Thread Eric Mendelson
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 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.
> 
>> 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

2016-07-10 Thread Keith Smith
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


Re: HealthChecker rc 0401 in rexx check

2016-07-10 Thread 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


IBM sold TWS (IWS) ???

2016-07-10 Thread Juergen Kehr
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