• Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Re: Calling JDE from external menues

Re: Calling JDE from external menues

We created a CL program (named JDEAPP) which is called from our menuing
program. This is what it does...




************** Beginning of data *********************************
PGM
DCL VAR(&LIBL) TYPE(*CHAR) LEN(275)

RTVJOBA USRLIBL(&LIBL)
ADDLIBLE LIB(JDFOBJ)
MONMSG MSGID(CPF0000)

CALL PGM(J98INITA)

RPLLIBL LIBL(&LIBL)
MONMSG MSGID(CPF0000)

END: ENDPGM
***************** End of data ************************************

Does that make sense? It works great. When users exit JDE they're back at
our master menu.

Susan
Century Theatres
JDE World A7.3 cum 11-AS/400
 

sraisor

Member
Re: Calling JDE from external menues

Chuck,

What we do is place the call to J98INITA on menus. When the user is
done with JDE menus then they type a 30 to exit back to the origional
(nonJDE) menu.

Steve Raisor

----- Original Message -----
From: "Graves, Chuck" <cgraves@roddapaint.com>
To: <jdeworldml@jdelist.com>
Sent: Friday, March 02, 2001 2:35 PM
Subject: Calling JDE from external menues


> Has anyone had any experience calling JDE (i.e. J98INITA) from another
> non-JDE system (i.e another systems menu driver pgm) and then returning
> to the other system when done with JDE functions? I am assuming that I
> need to modify J98INITA to go to EOJ via a function key, or some such
> mechanism...
 

miaconis

Active Member
RE: Calling JDE from external menues

We use a command here to start the JD Edwards system for the people in the
IS department. When we sign on to the AS/400 we are on an IBM menu. If we
type the command JDE we invoke the JD Edwards system, either directly into
the starting JDE menu or to the library list selection depending on whether
we have multiple environment capability or not. To sign off the AS/400 we
enter ".." or "90". To return to the IBM environment and stay signed on,
we enter "30". If we have multiple environments we have to press F3 after
we enter "30". Below is the source for the command and the associated CL
program.

COMMAND - JDE

0001.00 CMD PROMPT('Start JD Edwards')


CL - JDEC

0001.00 PGM
0002.00 DCL VAR(&JDE) TYPE(*CHAR) LEN(6)
0003.00 MONMSG MSGID(CPF0000)
0004.00 RTVDTAARA DTAARA(*LDA (11 6)) RTNVAR(&JDE)
0005.00 IF COND(&JDE *NE ' ') THEN(DO)
0006.00 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('You
are +
0007.00 currently running JD Edwards') +
0008.00 MSGTYPE(*ESCAPE)
0009.00 GOTO CMDLBL(ENDPGM)
0010.00 ENDDO
0011.00 ADDLIBLE JDFOBJ
0012.00 CALL J98INITA
0013.00 ENDPGM: ENDPGM


I hope this helps.
 

Emad_S_Banoub1

Active Member
Re: Calling JDE from external menues

--0__=m2bI6dZjxgRPoYgY2wqrteavnr8qBqsCxhqJe8M7O12hGOt7BD05XV5m
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



You do not need to modify J98INITA pgm. I have wrote an initial pgm to access
JDE and SW2000.
Basically create a simple menu with two options one for JDE and the other for
the second software, change the initial pgm parameter in IBM user profile to the
new initial pgm. Call me if you need more details

Emad Banoub - Sr. Systems Engineer
Montgomery Watson
626.568.6529
emad.banoub@mw.com




<P ID="edit"><FONT SIZE=-1>Edited by ekempter on 3/5/01 04:38 PM.</FONT></P>
 
Re: Calling JDE from external menues

Please do not take this personally, but this program contains one of the worse
things you can do in a CL program. Specifically:


> 0001.00 PGM
> 0002.00 DCL VAR(&JDE) TYPE(*CHAR) LEN(6)
> 0003.00 MONMSG MSGID(CPF0000)

This ^^^^^^^^^^^^^^^^^^^^^^^^^^

|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

This statement says "Monitor for any possible CPF error and keep the program alive,
but don't do anything to correct the error condition."

If the user were to trun off their terminal, this line will cause the program to
loop endlessly, chewing up as many CPU cycles as it could. It will be quite
difficult to end the job at that point.

If you're going to monitor for an error message, please, do something with it.
Don't just mask the error by monitoring and ignoring.

IMHO,

jte


>
> 0004.00 RTVDTAARA DTAARA(*LDA (11 6)) RTNVAR(&JDE)
> 0005.00 IF COND(&JDE *NE ' ') THEN(DO)
> 0006.00 SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) MSGDTA('You
> are +
> 0007.00 currently running JD Edwards') +
> 0008.00 MSGTYPE(*ESCAPE)
> 0009.00 GOTO CMDLBL(ENDPGM)
> 0010.00 ENDDO
> 0011.00 ADDLIBLE JDFOBJ
> 0012.00 CALL J98INITA
> 0013.00 ENDPGM: ENDPGM
>
> I hope this helps.
>

--
John Earl - VP / CTO
The PowerTech Group
Kent, Washington - 253-872-7788
johnearl@powertechgroup.com
www.400security.com
--
 

miaconis

Active Member
RE: Calling JDE from external menues

So what you are saying is line 3.00 should read:
0003.00 MONMSG MSGID(CPF0000) EXEC(GOTO ENDPGM)

Sorry. I didn't write the program so I won't take it personally, but it
has worked fine here for over 2 years. Perhaps it works fine because none
of us use terminals. Everyone has PCs and they don't cause a loop. I will
try this with a terminal if I can find one though. Thanks for the input.
 
RE: Calling JDE from external menues

It doesn't matter if you use terminals or PC's. The word "terminal" in this
case just means whatever you use to interface to the AS/400.

JGD

--------------------------------------------
James G. Donahue
Manager, Applications & Development
Paramount Parks Inc.
(704) 561-8111
 

Bonnie

Member
Re: Calling JDE from external menues

John, the code that you are talking about

(MONMSG MSGID(CPF0000))

is found in many of the JD Edwards CL programs. I don't like it either, but its there just the same.

Bonnie
 

Colin_Hugill

Reputable Poster
RE: Calling JDE from external menues

Dear all,

IMHO there is no problem with intelligent use of MONMSG MSGID(CPF0000). In
fact it is very useful approach to avoiding many minor problems and serves a
necessary purpose. MONMSG has been around and used for many years,
including the years of the S/38 before the AS/400 existed.

However I cannot overstress the emphasis on "intelligent use.."!!

Can we now agree that it is not a sin or some severe design glitch to use it
in programs, this way we might be able to reduce some of the e-mail traffic
out of JDELIST.

Regards...... Colin HUGILL

PS The plural form of "menu" is "menus" - even the spell checker from
Microsoft can detect this.
 

rtuohy

Member
Re: Calling JDE from external menues

There is no problem per se in using MONMSG as below, it is a perfectly
acceptable and common use of a 'catchall'. It simply prevents the program
falling over and allows the flow to continue to the end. Any program which
causes a loop because of this is extremely badly written. A typical use of
this code may be where a CPYF (copy file) in the CL may attempt to copy from
an empty member. If this does not affect the program processing, there is no
need to take any action, but failure to monitor for the error may cause the
program to hang waiting for operator/user action, or may cancel by default,
neither of which is at all useful and may create more problems.

Ron Tuohy
>
>John, the code that you are talking about
>
>(MONMSG MSGID(CPF0000))
>
>is found in many of the JD Edwards CL programs. I don't like it either,
>but its there just the same.
>
>Bonnie
>
>
>
>
>--------------------------
>To view this thread, visit the JDEList forum at:
>http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=W&Number=6693
>*************************************************************
>This is the JDEList World Mailing List.
>Archives and information on how to SUBSCRIBE, and
>UNSUBSCRIBE can be found at http://www.JDELIST.com
>*************************************************************
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
 

DBelcher

Active Member
RE: Calling JDE from external menues

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A63C.EA1B4C40
Content-Type: text/plain;
charset="iso-8859-1"

Bonnie,

You are correct that most, if not all, JDE pgms use the monmsg for CPF0000.
In fact the quick start CL option will generate it for you, however the code
showing here is incomplete. What it should show as is:

MONMSG MSGID(CPF0000 CPC0000 CPD0000) EXEC(GOTO CMDLBL(ABEND))

The critical piece is the goto ABEND which sends a msg that the "program
encountered one or messages..." and generates a joblog. With out those
pieces errors could occur without the users or IT knowing about it and being
able to correct it.

So, I have to agree with the original statement that it is a bad or sloppy
way of coding.

Doug Belcher
KV Pharmaceutical
St Louis MO
Opinions expressed are not necessarily those of my employer


>

Doug Belcher
St Louis MO
Opinions expressed are not necessarily those of my employer
 

rtuohy

Member
RE: Calling JDE from external menues

Doug, see my separate posting. The code without the GOTO is a perfectly
valid technique for trapping non fatal errors which the programmer does not
wish to prevent the program processing. Errors which are fatal should be
trapped separately with their own GOTO's. Relying on the catchall is sloppy
programming, proper use is not.

Ron Tuohy

>
>Bonnie,
>
>You are correct that most, if not all, JDE pgms use the monmsg for CPF0000.
>In fact the quick start CL option will generate it for you, however the
>code
>showing here is incomplete. What it should show as is:
>
> MONMSG MSGID(CPF0000 CPC0000 CPD0000) EXEC(GOTO CMDLBL(ABEND))
>
>The critical piece is the goto ABEND which sends a msg that the "program
>encountered one or messages..." and generates a joblog. With out those
>pieces errors could occur without the users or IT knowing about it and
>being
>able to correct it.
>
>So, I have to agree with the original statement that it is a bad or sloppy
>way of coding.
>
>Doug Belcher
>KV Pharmaceutical
>St Louis MO
>Opinions expressed are not necessarily those of my employer
>
>
> >
>
>Doug Belcher
>St Louis MO
>Opinions expressed are not necessarily those of my employer
>--------------------------
>To view this thread, visit the JDEList forum at:
>http://198.144.193.139/cgi-bin/wwwthreads/showflat.pl?Cat=0&Board=W&Number=6724
>*************************************************************
>This is the JDEList World Mailing List.
>Archives and information on how to SUBSCRIBE, and
>UNSUBSCRIBE can be found at http://www.JDELIST.com
>*************************************************************
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
 

DBelcher

Active Member
RE: Calling JDE from external menues

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0A64B.142EE6F0
Content-Type: text/plain;
charset="iso-8859-1"

Ron,

If I may disagree with you slightly. In the vast majority of cases you are
right, not trapping non-fatal errors which the programmer/user does not
need, is valid. Trapping for the fatal errors and handling them properly is
also valid. However, I tend to like to add the extra "insurance" of having
that final trap just in case there are changes in the system or programs
that I might not be aware of or account for. It adds code to every CL and
everyone in the shop needs to follow the standard in order to be effective.
On the other hand it gives the user immediate feedback and me a job log for
debugging if it occurs.

Doug Belcher
KV Pharmaceutical
St Louis MO
Opinions expressed are not necessarily those of my employer


>

Doug Belcher
St Louis MO
Opinions expressed are not necessarily those of my employer
 
Re: Calling JDE from external menues

Ron,

rtuohy wrote:

> There is no problem per se in using MONMSG as below, it is a perfectly
> acceptable and common use of a 'catchall'. It simply prevents the program
> falling over and allows the flow to continue to the end.

I'm actually a bit surprised at having to defend my original statement. The problem
with 'this catchall' MONMSG is that it is an indescriminate 'catchall'. Not only
does it catch the pesky little messages that might interupt your program needlessly,
it also will catch (and obscure!) those big ugly error messages that can and should
cause your program to fail. As I'm sure you are already aware, the CPF0000 is a
generic message ID that is used to trap all error messages from CPF0001 through
CPF9999. Placing that MONMSG as the first executable line in a CL program causes it
to act as a program wide "Global" error monitor. By monitoring for this error
message and then not taking an approriate error action, you are basically telling
the program "I don't care how big awful and scary the error message you receive is,
ignore the message and attempt to continue processing".

This can have potentially disasterous results. If one uses this global error
message monitor (MONMSG CPF0000) at the beginning of their CL program, you will not
be warned of any error condition that occurs. If for example you have aprogram call
RPGPROGA, and it's job is to process the daily orders from FILEB, and you have a CL
program that looks like this:

PGM

MONMSG CPF0000 /* but do nothing */

CPYF FROMFILE(FILEA) TOFILE(FILEB) MBROPT(*REPLACE)
CALL RPGPROGA /* Process daily orders */

ENDPGM

Imagine that one day there are no records in FILEA. The CPF2869 error message that
is generated by the CPYF statement would get supressed by the MONMSG CPF0000 (and
tthen do nothing) statement. This would cause the records that were left in FILEB
from yesterday to get reprocessed..... oooops!

However, if you remove the MONMSG CPF0000, or better still, you take some error
recovery action when it occurs (as Doug Belcher sugggested), then you would be
notified of the problem before it had a chance to corrupt your program. This is
called "coding defensively", and it is an excellent practice to take up. It helps
protect you and your data even if somebody else screws up.

Here is an example of the smae program, but with graceful error handling inserted:

PGM

/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
/* Declare message handling variables. */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
DCL VAR(&ERRORFLAG) TYPE(*CHAR) LEN(1)
DCL VAR(&MSGID) TYPE(*CHAR) LEN(7)
DCL VAR(&MSGDTA) TYPE(*CHAR) LEN(100)
DCL VAR(&MSGF) TYPE(*CHAR) LEN(10)
DCL VAR(&MSGFLIB) TYPE(*CHAR) LEN(10)
DCL VAR(&MSG) TYPE(*CHAR) LEN(80)

/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
/* Global monitor for messages */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(MESSAGE))

CPYF FROMFILE(FILEA) TOFILE(FILEB) MBROPT(*REPLACE)
CALL RPGPROGA /* Process daily orders */

/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
/* Error Handleing routine. */
/* Send error message */
/* Re-display screen */
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
MESSAGE: RCVMSG MSGTYPE(*DIAG) RMV(*NO) MSG(&MSG) +
MSGDTA(&MSGDTA) MSGID(&MSGID) MSGF(&MSGF) +
MSGFLIB(&MSGFLIB)
IF COND(&MSG *NE ' ') THEN(DO)
SNDPGMMSG MSGID(&MSGID) MSGF(&MSGFLIB/&MSGF) +
MSGDTA(&MSGDTA) TOPGMQ(*EXT) MSGTYPE(*COMP)
GOTO CMDLBL(MESSAGE)
ENDDO

MESSAG2: RCVMSG MSGTYPE(*EXCP) RMV(*NO) MSG(&MSG) +
MSGDTA(&MSGDTA) MSGID(&MSGID) MSGF(&MSGF) +
MSGFLIB(&MSGFLIB)

IF (&ERRORFLAG *EQ '1' ) THEN(DO)
RETURN /* Program is in a loop */
ENDDO

CHGVAR &ERRORFLAG '1'
IF COND(&MSG *NE ' ') THEN(DO)
SNDPGMMSG MSGID(&MSGID) MSGF(&MSGFLIB/&MSGF) +
MSGDTA(&MSGDTA) TOPGMQ(*EXT) MSGTYPE(*STATUS)
ENDDO


EXIT: ENDPGM


All this extra (seemingly superfluous) code will cause th eprogram to fail
gracefully by writing the error message to the joblog, and not giving the user a (C
D I R) screen that they can reply to! Now you will know of the fatal error, and
any diagnostic error that preceeds it.

It is much easier to fix problems if you know about them. MONMSG CPF0000 obscures
error messages from the user and the programmer, and is just trouble waiting to
happen.


> causes a loop because of this is extremely badly written. A typical use of
> this code may be where a CPYF (copy file) in the CL may attempt to copy from
> an empty member. If this does not affect the program processing, there is no
> need to take any action, but failure to monitor for the error may cause the
> program to hang waiting for operator/user action, or may cancel by default,
> neither of which is at all useful and may create more problems.

Without belaboring the point, if the CPYF of an empty member is a benign action in
your program, then a MONMSG CPF2869 directly after the CPYF statement is what you
need. A MONMSG CPF0000 (without an associated GOTO) as the first executable line in
the program (causing it to act as a global error monitor) is just reckless.


IMHO

jte


--
John Earl - VP / CTO
The PowerTech Group
Kent, Washington - 253-872-7788
johnearl@powertechgroup.com
www.400security.com
--
 
Top