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


  • Subject: Re: swap QTEMPs
  • From: Francesco Scafi <fscafi@xxxxxx>
  • Date: Thu, 16 Dec 1999 07:30:03 +0100

In this case it is necessary a target job...

At 14.15 13/12/99 -0800, you wrote:
>You can do something similar with a message queue without using MI. In the
>job you want to look at, create a message queue with a break handling
>program that will use received messages' text as an AS/400 command, and set
>the message queue's delivery to break. Then from any other job, simply send
>a break message to that queue with a command as the text.
>
>In the target job:
>CRTMSGQ MSGQ(lib/CMDQ)
>CHGMSGQ MSGQ(CMDQ) DLVRY(*BREAK) PGM(CMDQC)
>
>From any other job:
>SNDMSG MSG('dsplib qtemp *print') TOMSGQ(CMDQ)
>
>The break handling program:
>PGM PARM(&MSGQ &MSGLIB &MRK)
>             DCL        VAR(&MSGQ) TYPE(*CHAR) LEN(10)
>             DCL        VAR(&MSGLIB) TYPE(*CHAR) LEN(10)
>             DCL        VAR(&MRK) TYPE(*CHAR) LEN(4)
>             DCL        VAR(&MSG) TYPE(*CHAR) LEN(75)
>             RCVMSG     MSGQ(&MSGLIB/&MSGQ) MSGKEY(&MRK) MSG(&MSG)
>             CALL       PGM(QCMDEXC) PARM(&MSG 75)
>ENDPGM
>
>Note that if you send a command with interactive output to a batch job, the
>batch job will get an error, and that if you send that same command to an
>interactive job, the output will be on the interactive job's display, not
>yours.
>
>While this is not as convenient as having a normal library name pointing to
>the target job's QTEMP, it does allow other things as well, such as putting
>the target job into debug and looking at program variables.
>
>Peter Dow
>Dow Software Services, Inc.
>909 425-0194 voice
>909 425-0196 fax
>
>
>From: Gary Guthrie <GaryGuthrie@home.com>
>> Or how about storing a pointer to a permanent context (library) as a
>> pointer to QTEMP. I've done that before, too. That can be interesting.
>> It's handy for testing things done with another job's QTEMP objects. For
>> instance, you might have a job that's creating things in QTEMP and
>> things aren't going as expected. Create a permanent context, stuff it's
>> address in the PCO as if it's QTEMP, and let the job continue. Now from
>> another job you can perform all the normal OS/400 commands against the
>> job's QTEMP, because it's a permanent context with a normal library name
>> you can use in the commands.
>

+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.