× 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.



On 22-Dec-2014 14:57 -0600, Gary Thompson wrote:
On Monday, December 22, 2014 1:46 PM Tim Brown
On Dec 22, 2014 9:35 PM, Gary Thompson wrote:
On Monday, December 22, 2014 1:22 PM Tim Brown wrote:
>>
If you're seeing the message appear on the bottom of the screen
when you're running a transfer interactively then it's likely a
status message that arpsftp sends to show progress. <<SNIP>>

<<SNIP>> there is no mention in Arpeggio's manual, and, as
stated, no tracks in the job log <<SNIP>>

The message is just a status message and thus won't appear in the
joblog. <<SNIP>>

<<SNIP>> I did not know status messages don't show in the joblog -
doh!


Just a note of clarification...

While accurate that status messages will not appear in the joblog, the appearance of those messages, as seen in the message status line [sometimes referred to as line 24] of the [effective] /display file/ of the acquired device can occur only when the *STATUS messages have been sent to the External Program [Call] Message Queue (*EXT). Whether such messages will actually appear at the display for a[n interactive] job depends on the job attribute established via the Status Messages (STSMSG) parameter of Change Job (CHGJOB) or the *STSMSG special value for the User Option (USROPT) of the Change User Profile (CHGUSRPRF)].

<www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rbam6/preventsmg.htm>
_Preventing the display of status messages_

Conspicuously then, Status messages are not restricted to being sent only to the *EXT PgmMsgQ. Yet when not sent to the External queue, the status messages still will not appear in a joblog, as contrasted with other message types that will appear in the joblog according to the LOG filtering rules. That is because for a status message, irrespective of to what program message queue the message is sent "No message information is stored in a message queue" for the *STATUS message [that can only be sent to a program message queue; see msg CPD2525] and as a consequence, "a status message cannot be received" [by the Receive Message (RCVMSG) or the API]:
<www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_72/rbam6/ssmsg.htm>

But like the *ESCAPE message, the Sts and Ntfy message types are also of the Exception Message (*EXCP) class of Message Types; all other message types [e.g. *COMP, *INFO, etc.] are in the non-Exception class. Thus also why a status message that is sent to other than *EXT can act similar to an *ESCAPE message [/percolated/ in the same manner] in the receiving program, and why the Monitor Message (MONMSG) supports enabling a monitor; only those message types of the Exception Message (*EXCP) class, including *ESCAPE, *STATUS and *NOTIFY Message Type (MSGTYPE) can be monitored.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.