|
Simply savobj/rstobj will move the program and it will execute, assuming all necessary objects (files, data areas, called programs) are also present. One possible problem is performance. It the COBOL program is called repeatedely , ie. for a tax calculation on every line item of an invoice, you will probably suffer from poor performance. This is due to the implementation of the COBOL environment on the AS/400 & iSeries. When the program ends, all traces of the program environment are removed from your job, and must be recreatd the next time the program is called. Basically the same as ending an RPG program with LR on. To prevent the program environment from being cleared, there must be a COBOL program higher in the call stack. This can be accomplisehed by creating a simple COBOL program that calls the initial program for your job. (Or have someone create, compile, and save, then you can restore). By having the COBOL program at the top of the program stack, the called program will act like an RPG program that returns with LR off. Had this occur in an environment where the job took 11 HOURS to run. Same Job, Same Data, with a COBOL program that just called the initial RPG program, 17 MINUTES! (Been a while, it mighthave been 17 HOURS to 11 Minutes). The only cange was the addition of the one COBOL program. This was done without ever seeing the system. We were given the name of the program called to initiate the process, luckily there were no passed parms. Wrote, compiled, saved, then FTPed the save file in about 20 minutes. Talked them thru getting the FTP from their PC to AS/400 and restoring in about 30 minutes. Then got the call that it didn't work. "Why, what happened?" I asked. It only ran 11 minutes was the reply. "Did you check the output?" No, the job died. "Were there any error messages?" NO was the reply. "check the *&^%()&* output" I replied. Three hours later.... Phone rings, sheepish customer on the other end. "All the output is correct. "Imagine that. Guess that's why you called in the first place........ Gosh, I LOVE this business (bidnes, in texan)........ Bob Lakes Shane wrote: > Dear all, > > Just a quick question. If I have an AS/400 with a COBOL/400 program that is > compiled (executable code and no RPG on the machine) and provided that there > is nothing specific to that environment or AS/400 that the program would > uses, is it possible to send the executable code to and AS/400 that has no > COBOL/400 on it (only has RPG) and still get the program to run? I think it > should work but I am not 100% sure. Any insight would be appreciated. > > Thanking you in advance, > > Shane Lakes > > >************************************************************************************ > This email and any files transmitted with it are confidential and intended > for the addressee only. If you have received this information in error, > please notify the sender or Postmaster@lifetime.ie immediately and > delete this email. If you are not the intended recipient, any distribution > or copying of this email is strictly prohibited. > > Any views expressed in this email are those of the individual sender > unless the sender specifically states otherwise.This footnote also > confirms that this email message has been swept by MIMEsweeper > for the presence of computer viruses. > >************************************************************************************ > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > 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 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.