× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Just two options spring to mind;
The Attention key to get to a command line
SysREQ option 6: DSPMSG QSYSOPR 

Are both or any of those two not possible?

Regards,
Carel Teijgeler

*********** REPLY SEPARATOR  ***********

On 28-9-2006 at 14:53 Jeff Crosby wrote:

Can't set QSYSOPR to *BREAK.  It's specifically set to _not_ break so as
not
to interrupt the unattended backup.  This is per BRMS instructions.

Regarding being in a restricted state:

1) I wasn't.  QCTL was still up.
2) I wasn't going to start another job.  I was either going to display
QSYSOPR messages -or- end previous request.

-- 
Jeff Crosby
Dilgard Frozen Foods, Inc.
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531

The opinions expressed are my own and not necessarily the opinion of my
company.  Unless I say so.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx 
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jeff Young
Sent: Thursday, September 28, 2006 2:25 PM
To: Midrange Systems Technical Discussion
Subject: Re: What if console locked

The reason the console would not allow the Sys Req key was 
that you were in a Restricted Mode.
In this environment, all subsystems are ended, and QCTL (or 
your controling subsystem) is limited to a single job which 
must be the console.
This is a requirement for SAVSYS and some other SAVE ALL operations.
In this environment, AFIK, you have *no* way to get into the 
system other than the console job.
It is usualy a good idea to set the QSYSOPR msgq to *BREAK 
mode before you start so you can see and answer any messages.
If your job may send *INQ messages to another message queue, 
you should set that message queue to break mode also.
 
Hope this helps.
 
Jeff Young
jyoung@xxxxxxxxxxxx
Sr. Programmer Analyst
Dynax Solutions, Inc. 
A wholly owned subsidiary of enherent Corp. 
IBM e(logo)server Certified Systems Expert - iSeries 
Technical Solutions V5R2 IBM  Certified Specialist- eServer 
i5Series Technical Solutions Designer V5R3 IBM  Certified 
Specialist- eServer i5Series Technical Solutions Implementer 
V5R3 IBM Certified Systems Expert -- eServer i5 iSeries 
Technical Solutions V5R3 IBM e(logo) Certified Specialist - 
p5 and pSeries Technical Sales Support 



----- Original Message ----
From: Jeff Crosby <jlcrosby@xxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, September 28, 2006 1:58:46 PM
Subject: What if console locked


An incident happened yesterday that got me to thinking.  I 
slept on it and still don't have an answer, but it seems like 
it should be simple.

What happened is, during the 4am backup, run at the console 
from BRMS console, the system did not recognize the tape that 
was in the drive.  It had it as "SLT001" for I don't yet know 
what reason.  When I came in the system was stalled at that 
point.  QCTL was up and QINTER was down, which I expected.

But the BRMS console would not allow the Sys Req key.  Did 
nothing.  I have
1 twinax display left, which I went to and did an ENDJOB 
*IMMED on the BRMS console.  It did not take, so I had to 
wait 10 minutes and do ENDJOBABN.

During those 10 minutes I dinked around in iSeries access, 
creating a session called DSPJC.  (In my shop all sessions 
that start with DSP* go to
QCTL.)  From there I could have ended the console also.

Then it dawned on me what if this happened when:

1) TCP/IP wasn't up (therefore no iSeries access)
2) The console was locked and would not allow Sys Req
3) My last remaining twinax display (a 3180) had bit the dust

How would I have gotten in to the system to do anything?  
BTW, I have ops console direct attached.

What seems like the problem to me is the console not allowing Sys Req.

It seems like I'm missing something here . . .

--
Jeff Crosby
Dilgard Frozen Foods, Inc.
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531

The opinions expressed are my own and not necessarily the 
opinion of my company.  Unless I say so.


--
This is the Midrange Systems Technical Discussion 
(MIDRANGE-L) mailing list To post a message email: 
MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change 
list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, 
please take a moment to review the archives at 
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion 
(MIDRANGE-L) mailing list To post a message email: 
MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change 
list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, 
please take a moment to review the archives at 
http://archive.midrange.com/midrange-l.




-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.