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



What I neglected to add to my stripped down program was this:

ADDENVVAR ENVVAR(QIBM_QSH_CMD_ESCAPE_MSG) VALUE(Y) +
REPLACE(*YES)

The above tells QSH to send *ESC instead of *COMP, making it something that can
be monitored.

My test program now correctly includes the non-zero return code for an invalid
command. Interesting that I use the MONMSG to catch a QSH0005 when sent as an
*ESC message and needed to add logic to receive it when it was sent as a *COMP
message. When I use a valid command, QSH0005 is still sent as *COMP.

I think I finally have it now. Tomorrow is another day.

John McKee

Quoting rob@xxxxxxxxx:

Also, can you MONMSG a completion message? I don't think so. All that
you can monitor for in QSH is:

Error messages for STRQSH

*ESCAPE Messages
QSH0002 Error found with QSH session, reason code &1, errno &2.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From:
John McKee <jmmckee@xxxxxxxxxxxxxx>
To:
midrange-l@xxxxxxxxxxxx
Date:
04/15/2009 04:30 PM
Subject:
Re: CL type conversion error
Sent by:
midrange-l-bounces@xxxxxxxxxxxx



I need a nudge here. I wrote a stripped down program to issue a single
command
in QSH. Then, I ran it in debug mode to see the variables. This does
not make
sense at this point. First, the stripped down mimimal code:

0001.00 PGM
0002.00 DCL VAR(&Msgdta) type(*char) len(4)
0003.00 DCL VAR(&MSGID) TYPE(*CHAR) LEN(7)
0004.00 DCL VAR(&MSGTXT) TYPE(*CHAR) LEN(170)
0005.00 DCL VAR(&RETURNCODE) TYPE(*INT) LEN(4)
0006.00 DCL VAR(&RC) TYPE(*CHAR) LEN(5)
0007.00
0008.00 QSH CMD('ls')
0009.00 MONMSG MSGID(QSH0005) EXEC(DO)
0010.00 RCVMSG MSGTYPE(*COMP) RMV(*YES) +
0011.00 MSGDTA(&MSGDTA) +
0012.00 MSGID(&MSGID)
0013.00 CHGVAR VAR(&RETURNCODE) +
0014.00 VALUE(%BIN(&MSGDTA 1 4))
0015.00 CHGVAR VAR(&RC) VALUE(&RETURNCODE)
0016.00 ENDDO
0017.00 CHGVAR VAR(&MSGTXT) VALUE('RETURN CODE IS' *BCAT
&RC)
0018.00 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG)
MSGDTA(&MSGTXT) +
0019.00 TOMSGQ(MISC003)
0020.00 END:
0021.00 DMPCLPGM
0022.00 ENDPGM

Running in debug with breakpoint set on the DMPCLPGM command, I get this:

EVAL &msgdta:x
00000 40404040

EVAL &msgid:x
00000 40404040 404040.. ........ ....

EVAL &msgtxt:x
00000 D9C5E3E4 D9D540C3 D6C4C540 C9E24040 - RETURN CODE IS
00010 40404040 40404040 40404040 40404040 -

I am left wondering if something is removing the message, thus preventing
this
little program from seeing it. I have not done debug on a batch job in a
long
time. So, I was doing this interactively. If I type the QSH command on a
command line, I do see the QSH0005 message on the bottom of the screen.
But,
it does not seem to be here in this program.

John McKee

Quoting Tom Liotta <qsrvbas@xxxxxxxxxxxx>:

John McKee wrote:

This is so dumb. I have done type conversions in CL before and not
encountered
this. First time with CLLE, though.

Given this:

DCL VAR(&RETURNCODE) TYPE(*DEC) LEN(5 0)
DCL VAR(&RC) TYPE(*CHAR) LEN(5)
.
CHGVAR VAR(&RETURNCODE) +
VALUE(%BIN(&MSGDTA 1 4))

John:

I don't get that part unless this is pre-V5R3 CL. Why not make
&RETURNCODE an *INT instead of *DEC? Just grab the integer value and use
it.

I assume that you're trying to extract a binary (integer) value from a
MSGDTA() data structure.

Tom Liotta


CHGVAR VAR(&RETURNCODE) +
VALUE(&RETURNCODE + 240)
CHGVAR VAR(&RC) VALUE(&RETURNCODE)


A DMPCLPGM produces this for the two variables:

&RC *CHAR 5 ' '
&RETURNCODE *DEC 5 0 0

The HEX code for &RC is 4040404040
There is no HEX code for &RETURNCODE

I am trying to get the return code from a QSH session into a
printable form, for
a message. From previous attempts, I learned that in order to compare
&RETURNCODE to a numeric zero, I had to add 240, to make it F0. That
works
now. But, why is &RC still blanks?

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone 253-872-7788 x313
253-479-1416
Fax 253-872-7904
http://www.powertech.com
--
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.