Scott,
If I understand what you are saying instead of opening up each directory
I can use one opendir() statement that opens up
/transfer/WMS/Upload/MAPICS/. Then I read and process the text files
that are located in that directory. Then at the end of my readdir(DIR)
loop I can perform my closedir(Dir) command.
Then if I had only one opendir() statement the is run every 4 minutes it
could run up to 13 hours before have to end and resubmit the job?
Where can I change the system value for opening up directories?
Steve Seroogy
Business Analyst
Phone: (262) 544-4811 x2734
Fax: (262) 968-9372
Generac Power System, Inc
Hwy 59 and Hillside Road
Waukesha, Wisconsin 53187
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
rpg400-l-request@xxxxxxxxxxxx
Sent: Tuesday, August 21, 2007 2:41 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: RPG400-L Digest, Vol 6, Issue 837
Send RPG400-L mailing list submissions to
rpg400-l@xxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/rpg400-l
or, via email, send a message with subject or body 'help' to
rpg400-l-request@xxxxxxxxxxxx
You can reach the person managing the list at
rpg400-l-owner@xxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific than
"Re: Contents of RPG400-L digest..."
*** NOTE: When replying to this digest message, PLEASE remove all text
unrelated to your reply and change the subject line so it is meaningful.
Today's Topics:
1. MVC Architecture and transactions (Wilt, Charles)
2. RE: Beginning SQL question (Wilt, Charles)
3. Re: Usefulness of O-specs (Re: RPG Cycle) (Keith Carpenter)
4. Re: Usefulness of O-specs (Re: RPG Cycle) (James Lampert)
5. RE: MVC Architecture and transactions (Takken, Cor)
6. Re: Using opendir and closedir (Scott Klement)
----------------------------------------------------------------------
message: 1
date: Mon, 20 Aug 2007 17:03:26 -0400
from: "Wilt, Charles" <WiltC@xxxxxxxxxx>
subject: MVC Architecture and transactions
All,
Just wanted to open a discussion regarding MVC architecture and
transaction support.
Basically, which piece ideally handles doing the COMMIT or ROLLBACK?
Does the answer change when dealing with green-screen programs where the
view & controller are combined into a single program?
My stance is that the COMMIT / ROLLBACK belongs in the model portion.
The controller will be calling a procedure that either commits or rolls
back as required.
However, another developer prefers having the controller do the commit /
rollback. Besides "having been bit in that past" by procedures that do
their own commit/rollback, his argument is that you should avoid side
effects in a procedure. I can see his point if for instance, you've got
a current procedure that does one standalone function. Then in the
future, you come up with a new function, which wants to reuse the prior
function as part of a larger transaction.
The only thing I can think of would be to have a extra parm passed in to
the function which tells it if it is a standalone transaction or part of
a larger one.
Thoughts, comments, arguments for or against?
Thanks,
Charles Wilt
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307
wiltc@xxxxxxxxxx <mailto:wiltc@xxxxxxxxxx>
This e-mail transmission contains information that is intended to be
confidential and privileged. If you receive this e-mail and you are not
a named addressee you are hereby notified that you are not authorized to
read, print, retain, copy or disseminate this communication without the
consent of the sender and that doing so is prohibited and may be
unlawful. Please reply to the message immediately by informing the
sender that the message was misdirected. After replying, please delete
and otherwise erase it and any attachments from your computer system.
Your assistance in correcting this error is appreciated.
------------------------------
message: 2
date: Mon, 20 Aug 2007 17:06:48 -0400
from: "Wilt, Charles" <WiltC@xxxxxxxxxx>
subject: RE: Beginning SQL question
Only if the file is on the f-spec.
RPG doesn't have an issue the file is used as an external DS as Bob was
doing.
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of DeLong, Eric
Sent: Monday, August 20, 2007 4:17 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Beginning SQL question
It would most likely need a RENAME option on the F-spec. SQL defined
tables will name the record format the same as the table name. This
is not acceptable to RPG, which needs uniquely named resources...
Eric
This e-mail transmission contains information that is intended to be
confidential and privileged. If you receive this e-mail and you are not
a named addressee you are hereby notified that you are not authorized to
read, print, retain, copy or disseminate this communication without the
consent of the sender and that doing so is prohibited and may be
unlawful. Please reply to the message immediately by informing the
sender that the message was misdirected. After replying, please delete
and otherwise erase it and any attachments from your computer system.
Your assistance in correcting this error is appreciated.
------------------------------
message: 3
date: Mon, 20 Aug 2007 15:32:47 -0700
from: Keith Carpenter <carpcon@xxxxxxx>
subject: Re: Usefulness of O-specs (Re: RPG Cycle)
James Lampert wrote:
At any rate, though, I have said (twice now; this will be the third
time) that I've never been able to make constructive use of O-specs
(other than those generated by the compiler) or level breaks (other
than the aformentioned sticking an LR in the LEVEL column, for
statements to be executed when The Cycle is completed).
Sounds like you're expecting an answer.
O-specs only good for LR time output ?
Excluding the compiler (DDS) generated specs, O-specs can be used for
program defined reports and database output. For external database
updates, they can limit record updates/adds to certain fields.
Like the cycle, program defined O-specs are a bit depreciated. DDS is
preferred for reports, but given the wide spread use of O-specs, I'd say
the RPG community is divided on this one. Certainly more RPG
programmers use O-specs than the cycle.
That doesn't mean I haven't tried. Nor does it mean that I'm afraid to
learn. Some of us do not automatically assume that if something is
old, it must be obsolete.
But it could be. If you're optimistic, you should believe in progress.
This shouldn't be a purist thing (RPG means using the Cycle and all the
orginal features). RPG has evolved far beyond it's roots. I wouldn't
get hung up with trying to make use of O-specs. If you don't need 'em
than don't use 'em. But if you must, try writing a report with O-specs.
Usually, it takes less time that the equivalent report in DDS.
Keith
------------------------------
message: 4
date: Mon, 20 Aug 2007 15:48:26 -0800
from: James Lampert <jamesl@xxxxxxxxxxxxxxxxx>
subject: Re: Usefulness of O-specs (Re: RPG Cycle)
Keith Carpenter wrote:
This shouldn't be a purist thing (RPG means using the Cycle and all
the orginal features). RPG has evolved far beyond it's roots. I
wouldn't get hung up with trying to make use of O-specs. If you don't
need 'em than don't use 'em. But if you must, try writing a report
with O-specs.
Usually, it takes less time that the equivalent report in DDS.
Actually, that sounds like my point.
On one project in the past, I tried using control breaks, and got
nowhere.
While I write Cycle programs with some regularity, essentially using
them any time it makes more sense for the program to ride The Cycle
through a file than to walk through it, and (controlled by explicitly
turning on LR) any other time the program is in a "do until done"
situation, I've never written one that actually generates a spooled
report. Most of the time, they either use The Cycle interactively, or to
do SQL-type mass-updates with a fair amount of logic to generate the new
values (and, since they don't use SQL, with no need for SQL tools). Or
both.
As to using SQL for mass-updates, yes, that would be even quicker than a
Cycle program. If we had any SQL tools beyond CLI.
And if we had some gin, we could make gin-and-tonic. If we had some
tonic.
--
James H. H. Lampert
Touchtone Corporation
------------------------------
message: 5
date: Tue, 21 Aug 2007 07:13:53 +0200
from: "Takken, Cor" <cor.takken@xxxxxxxxxxxxx>
subject: RE: MVC Architecture and transactions
IMHO the COMMIT / ROLLBACK actions should belong in the part where the
business logic is lodged. This enables re-use of the underlying queries.
Tieing (.. Is that spelled correctly? Somehow that word seems...
Wrong-ish) the commit/rollback too deeply in hierarchy makes combining
the loose queries awkward (or even impossible). So I believe strongly in
developing loose queries, without commitment control allowing me to
combine all kinds or queries, and this combining is a part of the
business logic. The business logic is the part which defines when a
transaction is complete thus there the control over commitment control
should be placed.
That opens up another discussion over where the business logic should be
placed. :)
Cor
-----Original Message-----
From: rpg400-l-bounces+cor.takken=logicacmg.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+cor.takken=logicacmg.com@xxxxxxxxxxxx] On
Behalf Of Wilt, Charles
Sent: maandag 20 augustus 2007 23:03
To: RPG programming on the AS400 / iSeries
Subject: MVC Architecture and transactions
All,
Just wanted to open a discussion regarding MVC architecture and
transaction support.
Basically, which piece ideally handles doing the COMMIT or ROLLBACK?
Does the answer change when dealing with green-screen programs where the
view & controller are combined into a single program?
My stance is that the COMMIT / ROLLBACK belongs in the model portion.
The controller will be calling a procedure that either commits or rolls
back as required.
However, another developer prefers having the controller do the commit /
rollback. Besides "having been bit in that past" by procedures that do
their own commit/rollback, his argument is that you should avoid side
effects in a procedure. I can see his point if for instance, you've got
a current procedure that does one standalone function. Then in the
future, you come up with a new function, which wants to reuse the prior
function as part of a larger transaction.
The only thing I can think of would be to have a extra parm passed in to
the function which tells it if it is a standalone transaction or part of
a larger one.
Thoughts, comments, arguments for or against?
Thanks,
Charles Wilt
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307
wiltc@xxxxxxxxxx <mailto:wiltc@xxxxxxxxxx>
This e-mail transmission contains information that is intended to be
confidential and privileged. If you receive this e-mail and you are not
a named addressee you are hereby notified that you are not authorized to
read, print, retain, copy or disseminate this communication without the
consent of the sender and that doing so is prohibited and may be
unlawful. Please reply to the message immediately by informing the
sender that the message was misdirected. After replying, please delete
and otherwise erase it and any attachments from your computer system.
Your assistance in correcting this error is appreciated.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be
copied, disclosed to, retained or used by, any other party. If you are
not an intended recipient then please promptly delete this e-mail and
any attachment and all copies and inform the sender. Thank you.
------------------------------
message: 6
date: Tue, 21 Aug 2007 02:56:30 -0500
from: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
subject: Re: Using opendir and closedir
Hi Steve,
Each time you call opendir(), you open a connection to a directory.
It's very much like opening a file -- an open path is created to the
directory for you to work with. The opendir() API returns a pointer
that you use to refer to that open path.
For each value that opendir() returns, you MUST save it into a variable,
and you MUST call closedir() with the same value. That means that if
your program changes the value of the variable, you won't be able to
close the open path, and it'll stay open forever!
By default, each job has a limit of around 200 open IFS objects before
it starts failing. (that limit can be changed, but rarely needs to be.)
Based on the code you've posted, you never close the /transfer,
/transfer/WMS or /transfer/WMS/Upload directories. You save the open
file info into the "dir" variable, but then you overwrite the value of
"Dir" before you ever close the directory -- making it impossible to
close!
Now, I don't understand why you're opening each preceding IFS directory.
That's not normally necessary! I assume you needed it for some
diagnostic reason? I dunno... but people don't usually do that, and it
seems like a strange thing to do. It's not necessary for your program
to work correctly.
However, if for some reason you want to keep opening those directories,
you also need to close them. Just call closedir() prior to opening the
next one and close up that previously opened directory.
If you don't do that, you'll leave the directories open, and things will
start to fail after your program has been run enough times to run out of
file handles. At the default of 200, you'd hit the limit after your
program has been run about 60 times (give or take a few). If it's run
every 4 minutes, that'd be about 4 hours between failures.
Once it fails, it'd keep failing until you restarted the job.
It may happen more frequently if you have other IFS resources open in
your job. (Even if they're used by the OS)
Anyway -- either stop opening all those unnecessary directories, or make
sure they get closed and you won't have that problem anymore. If this
doesn't help, then please post information about the error. You're
populating a variable named 'errno' and 'errmsg' with useful diagnostic
error information, but you're not telling us what the values of these
are! That leaves us having to take wild guesses!
Steve Seroogy wrote:
I'm having problems with a program that was written using opendir and
closedir. This program is run every 4 minutes, We are opening one
directory at a time when it can't open it is creates a dump. The
problem is when it dump it continues to dump every 4 minutes and never
process the information the program was intending to process. It
seems
to start dumping at dump3 and then every time it runs it dumps at all
dump commands. Below is the code can some one give me advice. I don't
mind that it dumps but it should keeping dump every time is dumps. It
seems something is not getting reset prior to running again.
// Open upload directory -- must go through path one directory at a
CurrentDir = '/transfer/WMS/Upload/MAPICS/';
Dir = opendir('/transfer');
// in the case of errors, the program will retrieve the error numbe
// and description and create a dump.
If Dir = *null;
error_p = strerror(errno);
errmsg = %str(error_p);
dump 'dump1';
Endif;
Dir = opendir('/transfer/WMS/');
If Dir = *null;
error_p = strerror(errno);
errmsg = %str(error_p);
dump 'dump2';
Endif;
Dir = opendir('/transfer/WMS/Upload/');
If Dir = *null;
error_p = strerror(errno);
errmsg = %str(error_p);
dump 'dump3';
Endif;
Dir = opendir('/transfer/WMS/Upload/MAPICS/');
If Dir = *null;
error_p = strerror(errno);
errmsg = %str(error_p);
dump 'dump4';
Endif;
// read first file in directory
p_dirent = readdir(Dir);
Dow p_dirent <> *null;
//retrieve file name
DataFile = %subst(d_name:1:d_namelen);
If %trim(DataFile) <> '.' and %trim(DataFile) <> '..';
OpenDirWithFile = %trim(CurrentDir) + %trim(Datafile);
// set flags and open file (read only, exclusive open, text
dat
flags = O_RDONLY + O_SHARE_NONE + O_TEXTDATA;
FDCurrent = open(OpenDirWithFile : flags);
// FDCurrent will be -1 if there is an open error on the file
// it will contain a pointer value if it is successful
If FDCurrent < 0;
error_p = strerror(errno);
errmsg = %str(error_p);
dump 'dump5';
endif;
// Open file
If FDCurrent >= 0;
// retrieve file name without extension
//Position = 0;
//Position = %scan(CurExt : Datafile : 1);
// create new file name for history
//NewFile = %subst(Datafile:1:Position - 1) + NewExt;
NewFile = Datafile;
// create path and file name to write to history directory
HistoryFolder = '/transfer/WMS/Upload/MAPICS.SAVE';
Path = %trim(HistoryFolder) + '/' + %trim(Newfile);
// set file usage (create if not created, read/write,
clear)
Flags = O_CREAT + O_WRONLY + O_TRUNC + O_TEXTDATA;
//set file authority (open to everyone)
Mode = S_IRWXU + S_IRWXG + S_IRWXO;
// create file in new directory
NewfileD = Open(%trimr(path) : flags : mode);
// retrieve record count, close file if error cuz won't be
a
If fstat(FDCurrent : %addr(FileStat)) < 0;
error_p = strerror(errno);
errmsg = %str(error_p);
dump 'dump6';
callp close(FDCurrent);
EndIf;
// set data structure to value that is pointed to by
FileSta
p_statds = %addr(FileStat);
// retrieve record count by dividing file size by record
siz
Recordcount = st_size / %size(rddata);
// set number of reads to record count and goto pos of next
For Recno = 1 to RecordCount;
pos = (recno - 1) * %size(rddata);
callp lseek(FDCurrent : pos : SEEK_SET);
// set file data to Upload data structure (RecLen is a
va
// just contains the length of the record written to
Uplo
RecLen = read(FDCurrent : %addr(upload) :
%size(upload));
If RecLen < 1;
error_p = strerror(errno);
errmsg = %str(error_p);
dump 'dump7';
callp close(FDCurrent);
EndIf;
// save data to variable to write to history file
%subst(WriteData:1:%size(Upload)) = Upload;
// write the record to the mapics file
Callp WriteTofile();
// write data to history file
If write(NewFileD:%addr(WriteData):%size(WriteData))
< %size(WriteData);
error_p = strerror(errno);
errmsg = %str(error_p);
dump 'dump8';
callp close(FDCurrent);
EndIf;
Endfor;
// close current file
callp close(FDCurrent);
// delete file from current directory
Callp Unlink(OpenDirWithFile);
// close history file
callp close(NewFileD);
Endif;
Endif;
// read next file in directory
p_dirent = readdir(Dir);
Enddo;
callp closedir(Dir);
*inlr = *on;
Return;
/end-free
Steve Seroogy
Business Analyst
Phone: (262) 544-4811 x2734
Fax: (262) 968-9372
Generac Power System, Inc
Hwy 59 and Hillside Road
Waukesha, Wisconsin 53187
------------------------------
midrange.com
