IBM Mainframe Forum

Perhaps you should have read the help first! Have you tried PF3? If that does not work then you will have to get your session cancelled, restart your session and red the help before going back into the display.

These users thanked the author NicC for the post:

Mehdi shri (Tue Aug 14, 2012 12:18 pm)

Use the ATTN key. On PCOMM emulator, you can right click then push ATTN.

These users thanked the author Pedro for the post:

Mehdi shri (Wed Aug 15, 2012 10:12 am)

Auto refresh is terminated via the ATTN key, now depending on your 3270 emulator that key may be any number of keys, I have my ATTN key mapped to Esc key, you need to find your RESET key to get out of the X-SYSTEM, my reset key is Ctrl, so RESET then ATTN will terminate the auto update.

These users thanked the author Peter_Mann for the post:

Mehdi shri (Wed Aug 15, 2012 10:12 am)

Medhi,

You did not explain why you want to scroll down automatically.

How is typing BOT &3 better than, say, waiting 2 hours and then typing BOT?

Pedro
Because I want to see a log that registered by the system. We are testing programs so this log is matter for us to see the application's action and situation.

I want to see a log that registered by the system

I am not a tester, but think that watching the screen is not a good testing methodology**. When they open a defect for the missing message, you will be asked 'Did you get that message when we tested?"... your answer will be "Yes, and the proof I have is right here!" as you point to your head. My suggestion is to capture SYSLOG at the end of your testing then look for the messages that were supposed to be received.

Let's say that you have a 24 line screen; only about 20 lines are used for syslog. What if in the span of 3 seconds that 21 or more lines are written to syslog? You will likely miss some of them.

** Actually, visually seeing the log is okay for adhoc testing, but not so much for formal testing. Google for Rational Functional Tester

These users thanked the author Pedro for the post:

Mehdi shri (Tue Aug 21, 2012 1:41 pm)

In reality an application should NOT write to the system log/operator console unless operator action is required. Write diagnostics and informational messages to a file - SYSPRINT or SYSOUT depending on whether it is PL/1 or COBOL.

These users thanked the author NicC for the post:

Mehdi shri (Tue Aug 21, 2012 1:41 pm)

Hello,

In reality an application should NOT write to the system log/operator console unless operator action is required.

Most definitely!

Many organizations will abend offending jobs and/or will unkindly counsel the person responsible.

In fact, most organizations will no longer permit "getting" data from the console operator. . .

Several of my larger clients have gone "lights out" in the computer room - there are no operators manning the console(s). Routine responses are handled by automation products and "alerts" trigger a call or message to the "on call". The schedlling dept is staffed 24/7 in case there is a need to have manual intervention for restart/rerun situations.

Sorry - got on a roll

Back to the topic - notes to the testers/developers should NOT be written to the console.

notes to the testers/developers should NOT be written to the console.

Agree.

an application should NOT write to the system log/operator console unless operator action is required.

I understand, but not sure that I agree. The application can issue the WTL macro rather than WTO. The message goes to the log, but not to the console.

Some businesses are legally required to keep operational data for long periods of time. I imagine that it is easier to issue WTL and piggyback on the archiving already done for SYSLOG rather than to invent their own mechanism** to archive and manage and easily find and retrieve the application's operational information.

** SYSLOG is an easy mechanism to save operational info. But a better choice is the System Logger (aside from the similarity in names, they are unrelated). See "MVS Programming: Authorized Assembler Services Guide", SA22-7608.

Hello,

But a better choice is the System Logger

Yup, agree

d