|
RE: Re: DOW vs DOU >C $$FKEY WHEQ ##F03 (If F3 or F12 is >C $$FKEY OREQ ##F12 pressed, set loop exit) >C MOVE 'Y' #EXIT1 (What, you don't say MOVE YES #EXIT1 ?) I moved from a place(Syracuse NY) where we called the things you wear on your feet to play basketball "Sneakers". If you said "A pair of Sneaks" everyone there knew what you meant. It might sound stupid but there was never any confusion. I moved to Richmond VA and They didn't know what I was talking about. They called them "Tennis Shoes" EVEN if they never played Tennis! The point is "A rose is a rose" and "clarity is in the cognizance of the beholder" The AID byte via named constants etc. maybe perfectly clear to some folks and maybe even asthetically/intellectually defendable. Others (With different standards) may say "How much simpler can you get than saying (IN03 IFEQ *ON) or maybe (*IN12 IFEQ *ON)? These people may work in shops where *IN01 -> *IN24 are ALWAYS F-keys response indicators. Would they be wrong? (on the other hand I have never personally met a person who could tell me what function key *INKQ or *INKJ was without looking at the sky or his/her shoes (But if I said "*IN03 = F3, guess what Fkey *IN18 is", 100% get it right) I personally look at the following section of code(at bottom of this post) and say "You can make it simpler and more generic/clonable" Separate the Logic control from the Data manipulation code. If its a screen processing routine; 1. Then Present the screen, 2. Determine which function/enter key was pressed. and 3. Process the routine that handles THAT function/enter key. My mainline screen processing routine is generally about 20-30 statements It does not usually have any data manipulation at all, just control logic I have a S1ENTER key subr. for "Screen 1 Enter key" processing. It generally contains only CASxx or SELECT/WHEN functions. I have a subroutine for each function key. Only things that pertain to that function key are in there. Generally these do NOT have any CAS,SELECT, or IFxx statements. They just do the Fkey function thats it. And also I do not set flags or indicators to "Bubble" me up and out of numerous low level subroutines/DO loops. For example I personally have no problem with saying (*IN03 CASEQ *ON EXIT). in the mainline or even some low level functional subroutine. I have a subroutine called EXIT which uses the RETURN function. It may or may not set on *INLR in the particular program but THE ONLY WAY OUT of the program is that door. I find numerous RETURNS through out the program "Not Neat" The last line in my Mainline section is a Failsafe EXSR EXIT. Just my $.02 but I maybe wrong. John P. Carr EdgeTech C F1DISP BEGSR C EXSR F1INZ (any pre-screen processing) C MOVE 'N' #EXIT1 C #EXIT1 DOWNE 'Y' (loop continues until , C EXFMT FMT1 exit set) (#EXIT1 DOWEQ 'N' would also be valid but I tend to think in the negative.) C SELEC C $$FKEY WHEQ ##F03 (If F3 or F12 is C $$FKEY OREQ ##F12 pressed, set loop exit) C MOVE 'Y' #EXIT1 C $$FKEY WHEQ ##F04 C EXSR @@INQ1 (prompt/lookup inquiry calls) C OTHER C EXSR @@EDT1 (input field editing) C $ERROR IFNE 'Y' C EXSR @@UPD1 (file update) C EXSR @@INZ1 C ENDIF (Again, $ERROR IFEQ 'N' could also be used.) C ENDSL C ENDDO C ENDSR >C F1DISP BEGSR > >C EXSR F1INZ (any pre-screen processing) > >C 1 DOWEQ 1 (obvious never-ending loop, >C EXFMT FMT1 requires LEAVE to exit) > >C *INKC IFEQ *ON (leave loop if F3 or F12 is >C *INKL OREQ *ON pressed) >C LEAVE >C END > >C *INKD IFEQ *ON >C EXSR F1PRMT (prompt/lookup inquiry calls) >C ITER (return to screen) >C END > >C EXSR F1EDIT (input field editing) >C $ERROR IFEQ *ON >C ITER >C END > >C EXSR F1UPDT (file update) >C EXSR F1INZ >C ITER >C ENDDO > >C ENDSR > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This is the Midrange System Mailing List! To submit a new message, * * send your mail to "MIDRANGE-L@midrange.com". To unsubscribe from * * this list send email to MAJORDOMO@midrange.com and specify * * 'unsubscribe MIDRANGE-L' in the body of your message. Questions * * should be directed to the list owner / operator: david@midrange.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
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.