|
Fortunately, the problem occurs right away so I probably do not have to furnish you with ALL the code (although technically, that might be the better way). It appears VERY vanilla to me. Here are the pertinent statements: The ORDHDR format contains the date fields in question. ------------------------------------------------------------------ 79 800ASPMMA ACT SHP DATE - MO. 81 820ASPDDA ACT SHP DATE - DAY 83 840ASPYYA ACT SHP DATE - YR. 85 850ASPCCA ACT SHP DATE CENTURY 86 870SHPMMA EXPECTED SHIP DATE - MO ***** 88 890SHPDDA EXPECTED SHIP DATE DAY ***** 90 910SHPYYA EXPECTED SHIP DATE YR. ***** 92 920SHPCCA EXPECTED SHIP DATE CENT ***** 93 940BOMMA LAST BO DATE - MO. ------------------------------------------------------------------- ORDKEY KLIST KFLD ORD# KFLD BO# -------------------------------------------------------------------- *IN89 DOUEQ'0' ORDKEY CHAINORDHDR 8089 *IN89 CASEQ'1' LCKMSG END END --------------------------------------------------------------------- *IN80 IFEQ '1' MOVE '1' *INLR CLOSEORDW162 86 RETRN ELSE EXCPTRLS162 END EXSR DATES ==================================================================== DATES BEGSR MOVELSHPYYA REQYYA MOVELSHPMMA REQMMA MOVELSHPDDA REQDDA Z-ADD1 REQCCA -------------------------------------------------------------------- By this point, the month is 81 and the day is 00 instead 08.11. Theyar remains safely at 02. The 3 fields, SHPMMA, DDA, YYA are not mentioned ANYWHERE else in the program. I will include the next few lines of code as the dates are passed to an RPG ILE program to calculate a future date. Remember, the fields are screwed up BEFORE the call is made...maybe from the previous record some strange and magical curse was carried back to mess up the NEXT record? -------------------------------------------------------------------- MOVELSHPYYA XYA 20 MOVELSHPMMA XMA 20 MOVELSHPDDA XDA 20 CALL 'CALCETA' 26 PARM XMA PARM XDA PARM XYA --------------------------------------------------------------------- I hope you can shed some light here Jim cause all of us are under the impression that there is a heinous bug in our operating micro-code. >From: "Jim Franz" <franz400@triad.rr.com> >Reply-To: midrange-l@midrange.com >To: <midrange-l@midrange.com> >Subject: Re: This RPG problem is REALLY WEIRD... >Date: Thu, 11 Jul 2002 21:36:57 -0400 > >show the code... all the moves, etc >jim >----- Original Message ----- >From: "Rick Rayburn" <the400man@hotmail.com> >To: <midrange-l@midrange.com> >Sent: Thursday, July 11, 2002 2:34 PM >Subject: This RPG problem is REALLY WEIRD... > > > > Totally stumped people... > > > > 1. operating on V4.3, i170 machine > > > > 2. RPG 3 compiled program problem running in batch mode. > > > > 3. Invoice header file is the suspect and it is in a program that has > > been running clean, handling 1000 records per day for > > over a year. > > > > 4. 3 date fields...2 zoned each...mm,dd,yy eventually being moved into > > 3 other like defined fields to calculate a future date one month in > > advance. NO DATA STRUCTURES DEFINED ANYWHERE FOR THESE FIELDS. > > > > 5. Problem. chain made to file to bring in fields. > > > > mm=08, dd=11, yy=02. easy enough, right? Sure. 99.9% of the time. > > But 8 months ago something happened. And a few minutes ago, after > > thousands of invoices were processed over 8 months time, IT happened > > again. > > > > 6. The month became 81 and the day became 00! I know because I did a >SRVJOB > > and DEBUG and saw them! After I fixed the variables, the next invoice >comes > > in with the same EXACT date, 08.11.02...and NO PROBLEM! > > 8 months ago, i believe it was 02.11.02...is the "11" day messing this >up. > > > > 7. Now there is a MOVEL command to move the input fields to the SAME >EXACTLY > > DEFINED OUTPUT fields but what in heck does that have to do with the >fields > > being presented in a whacked out fashion? It sure looks like a TWILIGHT >ZONE > > shift to the left occurred (on a chain?). Geez, let's do the time warp > > again! > > > > HELP!!!!!!!! > > > > PS...we're upgrading to v5.1 late next month. > > > > _________________________________________________________________ > > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > > > _______________________________________________ > > 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. > > > > > > >_______________________________________________ >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. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.