The problem is that the master console is at one, unmanned remote location, the other consoles are at a local location. I'll try contacting the vendor, maybe they can help.
Gadi -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Lizette Koehler Sent: Wednesday, October 23, 2013 10:10 AM To: [email protected] Subject: Re: Command output not displayed on Console Gadi, If you are really running on OS/390 V2.8 then you may need the vendor to assist. But this release is not supported and the vendor may not be able to help. A couple of questions 1) Did the $DI,JOBNAME,STATUS go to the master console before the addition of the consoles? 2) Did they check all the consoles after the command was entered to see if they output went to a different console (not the master) 3) Did they try entering the command directly from the master console? Did the output get returned to the console that entered it? I went back to your original post $DI,CLASS,STATUS,JOBNAME Is not the problem. It only expands the Display Init command to include the JOBNAME and the STATUS of the job. The $DI command should go back to the console that issued the command. Which appears to be CONTROL-O. In the JES2 commands manual (z/OS V1.12) it states (I do not have a OS/390 V2.8 JES2 manual to verify it was doing this back then) The routing codes are specified in the ROUTCDE parameter of the WTO or WTOR macro. If you specify a message which contains no routing codes, MVST may provide one or more default routing codes, based upon the presence or lack of other queuing specifications. If you specify a message containing descriptor codes but no routing codes and no target console, MVS will not assign any routing codes but will attempt to queue the message to the console with master authority. If you specify a message containing no routing codes, no descriptor codes, and no target console, MVS will assign a default set of routing codes. This set of default routing codes is specified at MVS initialization on the DEFAULT statement in your CONSOLxx parmlib member. If a set of default routing codes was not provided on the DEFAULT statement, MVS will assign routing codes 1 through 6. If your message for $DI is HASP892 then there are no descriptor codes and the routing code will be as follows: The message will be routed in one of the following ways: According to the routing indicators specified by the operator According to the default routing instructions previously specified by the operator Back to the console that initiated the associated request. If you could provide the MSG/Descriptor codes for the $DI command and output from SYSLOG, that could be helpful. In SYSLOG it should be about 133 char line. The first 10 or so should be the MSG/Desc Codes. If you could copy and paste the first 20 characters of the line to the list, we could decipher what routing codes are being used. >From my z/OS V1.12 system with $DI and $DI,JOBNAME,STATUS I show a slight >difference between WLM INITs and non-WLM inits. The display goes back to >TSOID which issued the command. NC0000000 LPAR1 13296 00:48:24.86 TSOID 00000290 $DI MR0000000 LPAR1 13296 00:48:24.86 TSOID 00000090 $HASP892 INIT(1) 712 DR 712 00000090 $HASP892 INIT(1) STATUS=DRAINED,CLASS=, ER 712 00000090 $HASP892 INELIGIBLE_CLASS=(A-WLM),NAME=1 MR0000000 LPAR1 13296 00:48:24.87 TSOID 00000090 $HASP892 INIT(2) 713 DR 713 00000090 $HASP892 INIT(2) STATUS=DRAINED,CLASS=, ER 713 00000090 $HASP892 INELIGIBLE_CLASS=(A-WLM),NAME=2 NR0000000 LPAR1 13296 00:48:24.94 TSOID 00000090 $HASP892 INIT(40) STATUS=INACTIVE,CLASS=X,NAME=40,ASID=00D8 NR0000000 LPAR1 13296 00:48:24.94 TSOID 00000090 $HASP892 INIT(41) STATUS=INACTIVE,CLASS=X,NAME=41,ASID=01C2 NR0000000 LPAR1 13296 00:48:24.94 TSOID 00000090 $HASP892 INIT(42) STATUS=INACTIVE,CLASS=X,NAME=42,ASID=01B9 NR0000000 LPAR1 13296 00:48:24.94 TSOID 00000090 $HASP892 INIT(43) STATUS=INACTIVE,CLASS=X,NAME=43,ASID=00A3 NC0000000 LPAR1 13296 00:49:03.32 TSOID 00000290 $DI,JOBNAME,STATUS NR0000000 LPAR1 13296 00:49:03.32 TSOID 00000090 $HASP892 INIT(1) STATUS=DRAINED NR0000000 LPAR1 13296 00:49:03.32 TSOID 00000090 $HASP892 INIT(2) STATUS=DRAINED NR0000000 LPAR1 13296 00:49:03.32 TSOID 00000090 $HASP892 INIT(3) STATUS=DRAINED NR0000000 LPAR1 13296 00:49:03.32 TSOID 00000090 $HASP892 INIT(4) STATUS=DRAINED NR0000000 LPAR1 13296 00:49:03.32 TSOID 00000090 $HASP892 INIT(5) STATUS=DRAINED You may have to have your Operators use a TSO Session with SDSF to see everything they need to see. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Lizette Koehler > Sent: Tuesday, October 22, 2013 11:29 PM > To: [email protected] > Subject: Re: Command output not displayed on Console > > You could open a case to BMC and request further help. I usually find > the vendor > support areas most helpful. > > > > If you could post the command issued by Control-O to show us the extra > information, we might be able to make suggestions. > > Lizette > > > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[email protected]] On Behalf Of ??? ?? ??? > > Sent: Tuesday, October 22, 2013 11:22 PM > > To: [email protected] > > Subject: Re: Command output not displayed on Console > > > > I'm not very proficient in Control-O. > > Does anyone have a suggestion on how to fix this? > > All the Control-O rule does is add some extra parameters to the $DI > command. > > > > Gadi > > > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:[email protected]] On Behalf Of [email protected] > > Sent: Wednesday, October 23, 2013 9:12 AM > > To: [email protected] > > Subject: Re: Command output not displayed on Console > > > > > The command output shows INTERNAL. Are you issuing the command > > > from the > > internal reader or thru some strange product? Is there an automation > product that is > > suppressing the original command and re-issuing it with the options? > > > > The command was issued from STC09092, which he said is control-O. My > > guess > is > > that the command was issued using some CONTROL-O interface (that I > > don't know), which in turn is using MGCRE *without* an explicitly > > defined EMCS > console > > and instead using console id 0 which translates to INTERNAL. And > > Control-O apparently doesn't get the responses to a command and > > displays them > properly. > > > > The question is if the operators can see the command response when > > they > use a > > true console and issue the command directly. > > > > Barbara > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to > [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
