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



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.
--
[ Picked text/plain from multipart/alternative ]
Barbara:

Thanks for your reply here.  This clears things up a lot for me as to why my
service program was bombing originally.  I was doing exactly what you
describe in the last paragraph of your e-mail.

Dave

-----Original Message-----
From: bmorris@ca.ibm.com [mailto:bmorris@ca.ibm.com]
Sent: Thursday, March 07, 2002 4:47 PM
To: rpg400-l@midrange.com
Subject: RE: SRVPGM: USROPN file or not



>From: "Bob Cozzi \(RPGIV\)" <cozzi@rpgiv.com>
>Date: Thu, 7 Mar 2002 14:17:47 -0600
>
>User Controlled Open (USROPN) gives you the ability to avoid
>having RPG IV automatically open the file for you, using the
>RPG cycle.
>
>Service program do not have an RPG Cycle embedded in them.

Bob, non-NOMAIN modules in service programs do have an RPG cycle.
And NOMAIN modules still have a bit of the RPG cycle (most of the
*INIT phase).  This bit runs when the first procedure is called
in the module.  It sets up the PSDS, opens non-USROPN files, reads
in UDS data areas, initializes fields.

This shows the details of subprocedure initializion:
http://publib.boulder.ibm.com/pubs/html/as400/v5r1/ic2924/books/c092508388.h
tm

>The ability to use the OPEN and CLOSE operation codes has nothing
>to do with the USROPN keyword. A file could be opened outside of
>the program or in your case, Service program.

You're right about OPEN and CLOSE having nothing to do with USROPN.
But for RPG to use a file, it has to be opened in that module.  You
can't open a file in one module and read it in another.  (You can
do the "real" open in one module and a shared open in another, but
you still need to do either an implicit open or do an OPEN operation
in each module that wants to do I/O.)

The message that started this thread is just a warning.  We issued
it to make sure people realized that their files wouldn't get closed
automatically.  Normally the only downside of not closing files is
that the files stay open (maybe no big deal).  But if the module is
in a *CALLER service program running in the default activation
group, and you do RCLRSC, then open files will get closed, but the
RPG static storage won't get cleared.  Next time you call a procedure
in the module, it thinks the file is still open and you get the
MCH3402 when you try to do I/O.  (This is the main really-bad-thing
that can happen with *CALLER-defaultAG.  It only applies to service
programs.)

Barbara Morris

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.