System - S20 2 IPCS cards, Domino Native, V4R2, gateway through Advantis WAN to internet. Has anyone had trouble routing mail from native Domino through a firewall set up on the AS/400 on the IPCS card?
System - S20 2 IPCS cards, Domino Native, V4R2, gateway through Advantis WAN to internet. Has anyone had trouble routing mail from native Domino through a firewall set up on the AS/400 on the IPCS card?
But I'm not interested in how to produce a job log. Inside the help text for the LOG parameter in CHGJOB is, "If the end of job code is 20 or higher ....." What is this "end of job" code? I have a hunch the job end code determines whether or not the system will send CPF1421 "Job ##/##/## completed normally", or CPF1420, "Job ##/##/## ended abnormally", when a batch job ends. A routing program that monitors for unhandled exceptions will always force the system to report a CPF1421. Sometimes the routing program decides that a CPF1420 would be more appropriate. What does a routing program have to do in order to make the system report a CPF1420, instead of a CPF1421, when the job ends? Can it set its own "job end code" to 20? How does it do that?
Gene, I am definitely not an expert, but I believe you are going down the right road. Each message has a severity level. So, when the program ends it looks at the severity levels of the previous unhandled (or completion) messages and makes a decision as to which of the final completion message to send. As to how to make a job end "normally" instead of abnormally, one way this is done is with the global MONMSG at the beginning of the CL code. These always end with a normal status. Bill Gene Gaunt wrote: But I'm not interested in how to produce a job log. Inside the help text for the LOG parameter in CHGJOB is, "If the end of job code is 20 or higher ....." What is this "end of job" code? I have a hunch the job end code determines whether or not the system will send CPF1421 "Job ##/##/## completed normally", or CPF1420, "Job ##/##/## ended abnormally", when a batch job ends. A routing program that monitors for unhandled exceptions will always force the system to report a CPF1421. Sometimes the routing program decides that a CPF1420 would be more appropriate. What does a routing program have to do in order to make the system report a CPF1420, instead of a CPF1421, when the job ends? Can it set its own "job end code" to 20? How does it do that?
Here's another one that a friend highly recommended to me. I haven't used it much yet.
On Saturday, October 10, 1998, 12:04 PM, Frank Whittemore wrote: I would like to nominate href="http://www.metacrawler.com"> href="http://www.metacrawler.com">http://www.metacrawler.com as the best general purpose Internet search engine. I would like to challenge others to name an ever better search engine if they can find one.
On Sunday, October 25, 1998, 12:34 PM, Rich Reeve wrote: Does anyone know how to insert carriage return/line feed characters in to a file created on the 400 using cobol. The file is a comma delimited ASCII text file that will be downloaded to a p.c. using FTP. Thanks for any assistance. Rich Reeve Rich, I don't know how you are creating your ASCII text file, but IBM added a new command with V4R3 call CPYTOIMPF (also CPYFRMIMPF), Copy To/From Import File. They will take an AS/400 file and copy it to/fro m an ASCII text file. With the copy to import file command you can specify field delimiters, and seperators. Also you can specify an end of record character of CR/LF, LF, CR, LF/CR, or any other character. To get this on V4R1 or V4R2 you need to download two PTFs. They are on the latest cume. On V4R2 the PTFs are SF46911 and SF46976. The command is a little flakey, the help text is all uppercase and refers to values the command will not accept. Overall it has been useful to us. David Morris
On Friday, October 30, 1998, 06:10 AM, Ted Holt wrote: Here's another one that a friend highly recommended to me. I haven't used it much yet. ************************************************** ******************** Ted - That's a good one, but it's the one that I personally switched from when I switched to my new favorite href="http://www.metacrawler.com"> href="http://www.metacrawler.com">http://www.metacrawler.com I like being able to see which search engines it actually uses plus it ranks the web page of my main client first. href="http://www.inference.com/infind"> href="http://www.inference.com/infind">http://www.inference.com/infind a> ranks my main client's web page 3rd or 4th. Let us know what you think after using them both for a while. Just an old mainframer caught in the Web!
Dave, this was an interesting thread you started. I have consistently used job date, not system date, in my applications thru the years, and never had the types of problems others have raised. Also, I'm surprised that no one said that it's often best not to use either one. Many programs I have written prompt for a date, and use whatever's entered to select data, build transactions, or whatever.
On Thursday, October 15, 1998, 09:43 AM, David Abramowitz wrote: Under normal and usual circumstances, there is no difference between the System Date, and the Job Date. Testing for potential Y2K problems necessitates changing the dates. As it is not recommended that the system date be changed, a job description may be created with a specific date, or the job date may be changed interactively. snip
On Friday, October 30, 1998, 06:43 PM, Ted Holt wrote: Dave, this was an interesting thread you started. I have consistently used job date, not system date, in my applications thru the years, and never had the types of problems others have raised. Also, I'm surprised that no one said that it's often best not to use either one. Many programs I have written prompt for a date, and use whatever's entered to select data, build transactions, or whatever. On Thursday, October 15, 1998, 09:43 AM, David Abramowitz wrote: Under normal and usual circumstances, there is no difference between the System Date, and the Job Date. Testing for potential Y2K problems necessitates changing the dates. As it is not recommended that the system date be changed, a job description may be created with a specific date, or the job date may be changed interactively. snip Ted & Dave, We used to use *JOB in most cases. We did have some problems when a job ran past midnight, especially if it mixed *JOB and system date in a series of programs. This happened to us a few times in programs that used the PSDS to retrieve the current date. Another thing that has not been mentioned is a date function wrapper, although it is too late to be of any use for Y2K remediation. We never refer directly to the system or job date in any program with the exception of audit dates. We adopted this standard as well as a date field type only on files about 6 years ago. We have found it really easy to test programs with date code. It also provides more flexibility in processing dates. For example we have a format that allows *MD as a shorthand entry. It is just a 6 month window. The users here really like this. We have had some problems recently with trigger programs and display files that referenced date type fields. As we recompile display files the system does not let an invalid (IE: *MD) entry through to the program. This doesn't cause any invalid data to be passed, it just prevents our own date formats from being passed. It would be nice if IBM let us specify our own date format/edit exit programs. David Morris