Level 78
in [Cobol]
|
Prev: all
Next: Open Cobol is free and standard.
From: Richard on 15 Feb 2010 12:47 On Feb 15, 8:20 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> wrote:> > CONSTANTS - LEVEL 78 > > A level 78 is a CONSTANT value stored in Working-Storage which may > contain either numeric or alphabetic values. The values cannot be > changed without a re-compile. Numeric values can be used for > calculations, maximum sizing tests etc. > > Some examples follow : > > 78 UKVatRate value 0.17. > 78 CanadianGST value 5. > 78 MongolianVAT value 4.23. > > 78 HarrysName value "Harry". > 78 LulusName value "Lulu". I think that you have illustrated the fundamental problem with 'constants'. Many of these are not actually constant and it requires a recompile to change them. It is (IMHO) a matter of good system design to have as few items as possible that would require the program to be recompiled. A configuration file, or a file or database table for unrelated data should hold these values. In my systems that go back up to thirty years even the file-status values are in a data table, with descriptions, which makes it easy to adjust for the different compilers. OpenCobol 'Record Locked' is '51'.
From: Clark F Morris on 15 Feb 2010 15:35 On Mon, 15 Feb 2010 09:47:01 -0800 (PST), Richard <riplin(a)Azonic.co.nz> wrote: >On Feb 15, 8:20�pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> >wrote:> > > >> CONSTANTS - LEVEL 78 >> >> A level 78 is a CONSTANT value stored in Working-Storage which may >> contain either numeric or alphabetic values. The values cannot be >> changed without a re-compile. Numeric values can be used for >> calculations, maximum sizing tests etc. >> >> Some examples follow : >> >> 78 UKVatRate � � � � � � � � � �value 0.17. >> 78 CanadianGST � � � � � � � � �value 5. >> 78 MongolianVAT � � � � � � � � value 4.23. >> >> 78 HarrysName � � � � � � � � � value "Harry". >> 78 LulusName � � � � � � � � � �value "Lulu". � � � � � � � � � � � � � � � � � � � � >I think that you have illustrated the fundamental problem with >'constants'. Many of these are not actually constant and it requires a >recompile to change them. > >It is (IMHO) a matter of good system design to have as few items as >possible that would require the program to be recompiled. A >configuration file, or a file or database table for unrelated data >should hold these values. > >In my systems that go back up to thirty years even the file-status >values are in a data table, with descriptions, which makes it easy to >adjust for the different compilers. OpenCobol 'Record Locked' is '51'. This is a matter of optimization and trade-off. How often do the values change? Would a recompile be needed to properly use the new values regardless of whether they were hard coded? Reading values from an external source takes time and the values can't be in a shared area. My own preference for things like file-status is to have the values hard coded, preferably in a copy book. If a module is to be multi-platform, I would have a copy book for each platform. I see no point in reading (and validating) those codes every execution.
From: Richard on 15 Feb 2010 16:25 On Feb 16, 9:35 am, Clark F Morris <cfmpub...(a)ns.sympatico.ca> wrote: > On Mon, 15 Feb 2010 09:47:01 -0800 (PST), Richard > > > > <rip...(a)Azonic.co.nz> wrote: > >On Feb 15, 8:20 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> > >wrote:> > > >> CONSTANTS - LEVEL 78 > > >> A level 78 is a CONSTANT value stored in Working-Storage which may > >> contain either numeric or alphabetic values. The values cannot be > >> changed without a re-compile. Numeric values can be used for > >> calculations, maximum sizing tests etc. > > >> Some examples follow : > > >> 78 UKVatRate value 0.17. > >> 78 CanadianGST value 5. > >> 78 MongolianVAT value 4.23. > > >> 78 HarrysName value "Harry". > >> 78 LulusName value "Lulu". > >I think that you have illustrated the fundamental problem with > >'constants'. Many of these are not actually constant and it requires a > >recompile to change them. > > >It is (IMHO) a matter of good system design to have as few items as > >possible that would require the program to be recompiled. A > >configuration file, or a file or database table for unrelated data > >should hold these values. > > >In my systems that go back up to thirty years even the file-status > >values are in a data table, with descriptions, which makes it easy to > >adjust for the different compilers. OpenCobol 'Record Locked' is '51'. > > This is a matter of optimization and trade-off. How often do the > values change? Would a recompile be needed to properly use the new > values regardless of whether they were hard coded? Reading values > from an external source takes time and the values can't be in a shared > area. In what way are the values prevented from being in a 'shared area' ? Is this something specific to a particular environment such as CICS ? As for 'reading values takes time', that hasn't been a problem (for me) for a few decades now. Machines that I run multi-user systems on can do 120Mb/sec from disk and 2000Mb/sec from cache and cost $1000 or so. > My own preference for things like file-status is to have the values > hard coded, preferably in a copy book. If a module is to be > multi-platform, I would have a copy book for each platform. I see no > point in reading (and validating) those codes every execution.
From: James J. Gavan on 17 Feb 2010 00:59 Richard wrote: > On Feb 15, 8:20 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> > wrote:> > > >>CONSTANTS - LEVEL 78 >> >>A level 78 is a CONSTANT value stored in Working-Storage which may >>contain either numeric or alphabetic values. The values cannot be >>changed without a re-compile. Numeric values can be used for >>calculations, maximum sizing tests etc. >> >>Some examples follow : >> >>78 UKVatRate value 0.17. >>78 CanadianGST value 5. >>78 MongolianVAT value 4.23. >> >>78 HarrysName value "Harry". >>78 LulusName value "Lulu". > > I think that you have illustrated the fundamental problem with > 'constants'. Many of these are not actually constant and it requires a > recompile to change them. > It may well illustrate a weakness, but that wasn't my intent :-). Similarly I included alpha literals, to show they *could* be used. But I haven't a single thought where they could be applied. Back to my examples :- 01 ErrorCode pic x(4) comp-5 *> or pic 9(03). 88 NoErrors value 0. 88 NameMissing value 1. 88 AddressMissing value 2. 88 ... 88 LastCurrently value 35. 88 ValidErrorCode value 0 thru 35. *> or 1 thru 35, depending upon *> your coding style 78 NM value 35. *> NM = Number of Messages 78 ML value 30. *> ML = Message Length 01 MessageTable. 05 pic x(ML) value "Customer name is missing". 05 pic x(ML) value "Address missing for Customer". 05....... 05 ....... 01 Filler redefines MessageTable. 05 ErrorMessage pic x(ML) occurs NM. As regards my usage above, those Level 78's are source code editing 'helpers', and once I'm finished they are CONSTANTS cast in stone. Yes, this is to do with approach, but even writing to data files as you do, I'm sure the same principle must come into play. Whether you are doing something to edit a dialog/screen for a Customer or DataAndTime as above, there are a set of errors which you will know about from experience, before you put pen to paper, or start keyboarding. You can immediately add the Level 88s for those under ErrorCode, and depending upon your style, add this known group as the first literals under 01 MessageTable. As you choose, you can do the literals later. However, I take the problem step-by-step and as I come across a potential error-condition, dream up the name to describe it and can add the line "set Error-NameMissing to true" and make an entry for Error-NameMissing as the next Level 88. (Sometimes do, sometimes don't, automatically go and add a literal for that ErrorCode under 01 MessageTable. (On reflection it is better to do this as a two step operation so that the ErroCode Level 88 and the MessageTable literal are the same index number). *** With reference to this, look at my comments about Messageboxes below. You make a decision on what the Message Literal should contain. You can't be firm on this; some modules lend themselves to short, crisp and clear messages. DateAndTme does because I don't display Windows Messageboxes. It is a tool for developers - so I return to you through the invoke linkage :- 01 lnk-Values. 05 lnk-Result pic x(4) comp-5. 05 lnk-Object object reference. lnk-Result - zero if it is OK or the particular ErrorCode Number lnk-object - zero it contains the date/time information in the format you requested - non-zero, the literal description for the ErrorCode Over and above those errors you foresee there are also those which can occur, because of the conditions you have set in writing a particular class or program. Good example, we'll keep it simple, but you can do permutations on this. My correspondent in Sweden told me that he enters dates as EUFormat-6 (ddmmyy), his reasoning, it's quicker for the user. But for data storage and the absolute ideal sort key wants a validated date returned as ISOFormat-8 (ccyymmdd). Good for him. So for that request, four parameters, because he wants a user date from an entryfield validated and then stored :- - (1) InputFormat-EU6 - (2) InputType = Numeric - (3) three Options on Values - only needs Value-1 = entryfield date passed as a numeric value - (4) Lnk-object above contains ISOFormat-8 numeric - ccyymmdd the result returned from the method invocation Not too many problems with that; well there are potential problems. # (1) above; a developer accidentally submits he/she wants InputFormat-EU8 (ddmmccyy) and #(3) they give me (correctly), Value 1 = a numeric as ddmmyy. I don't know what the S.Americans do - I'm guessing in both Portuguese and Spanish they are accustomed to using EnglishDates, (because of sales to the States and Canada), and Portuguese or SpanishDates. (The language used to get at Day or Month names is irrelevant to the problem being posed). As they are in the Americas, do they always use NA-Format8 (mmddccyy) NA-Format6 (mmddyy). Do they perhaps sometimes use EUFormat-8 (ddmmccyy) and EUFormat-6 (ddmmyy) ? I kid you not, up here in the Great White North, where as yet it hasn't been resolved, us Canucks use all six formats which also includes ISOFormat-8 (ccyymdd) and ISOFormat-6 (yymmdd). Not likely it will ever be resolved - la belle province will always do its own thing :-). Over and above know error-conditions, the above is to illustrate where additional error conditions can occur, as and when you hit them when writing your validation code. So just add the next one to the list. Now if instead of those Level 78s I have above, if I did it in 'traditional' style with a numeric value, it can become a real pain. 01 MessageTable. 05 pic x(25) value "Customer name is missing". 05 pic x(25) value "Address missing for Customer". 05 ....... 01 Filler redefines MessageTable. 05 ErrorMessage pic x(30) occurs 10. Initially it might have seemed to me that a pic x(25) was adequate but having entered some eight pic x(05)s and then I get to the literal "Address missing for Customer". Two choices, let the compiler pick up on your error, " value of literal = 28, size specified = 25 ", which means changing or first having noted it yourself, do a global replace from pic x(25) to pic x(30) on that group. As I ad lib with adding new ErroCodes the number increases for the 'occurs 10' to perhaps 'occurs 18'. At this point in time DateAndTime has some 30 ErroCodes, but I know from memory, because I changed the coding logic, there are at least three irrelevant. (If I leave unused codes there, eventually I will be puzzled myself should someone query the source). For tidiness I want to drop those when I go back and find them. That implies change the occurs 10 in the small example above. But I use the Level 78 NM value - and that leads on to the next topic. Bear in mind of course having done tests and using Level 78's I'll find some errors I hadn't originally picked up on. So now increase the ErroCodes and increase just the one 78 NM value 38 I'm completely finished coding - I think. Those Level 78s have concrete values, and at this point in time they are true unchangeable CONSTANTS. Assuming somebody said how about including number of weeks routines, covering things like accounting periods - I'm familiar with a 52 or 53 week year in retailing and quarterly reports in Unigate of 4:4:5. From the little I've read on the Web I get the impression it is pretty iffy. But suppose I did add Week features ? That could result in further ErroCodes when checking input and yes the CONSTANTS change once again - but the resultant recompile was necessary anyway to accommodate the new methods for week routines. (OK in OO I could sub-class the week routines do that it doesn't upset the source for DateAndTime - but to be honest I think that is messy in this situation). *** MessageBoxes Even if you don't buy into OO, (and that includes the guy who conned his tutor by making his thesis topic about "OO" which appealed to the tutor, even though still today he doesn't believe in OO; let those young Johnnies do it with Java or whatever :-) ), I think we can take it as read, even if you have never coded them, what Messageboxes are about. It was only earlier when I was at the point where I typed the original set of asterisks, that it struck me how seamless OO can be. (Not the same words but you oft have read that sort of statement from another person here, before). You write something, it works and you even forget about its inner workings. I have no intention of trying to teach my 'audience to suck eggs'. However Windows Messageboxes do have Icons, indicating 'Information', 'Warning' etc. Similarly you can select form a combination of Pushbuttons, Abort, Retry, Cancel, Yes, No, OK etc. For the reasons stated above, DateAndTime doesn't generate Messageboxes. But GUIs (Dialogs etc), classes covering COBOL files (file status) and classes covering individual SQL Tables do (SQLErrorCodes). Before I go further the sequence on displaying Messageboxes :- -------------------------------------------------------------------- Business Driver = Control/Business Logic and even the dreadful academic name 'Problem Domain' Without a decent graphic design it is difficult to illustrate but there are the same connecting lines from : - Business Driver to (1), (2) and (3). - And from from (1) to (1a), (2) to (2a) and (3) to (3a) leading to MyMessages ---------------------------------------------------------------- (1) Customer (1a)Error Edit Table Bus.--> (2) Customer--> (2a)FileStatus---> My- --> M/F GUI Driver ISAM File Table Messages Class MessageBox (3) Customer (3a)SQLError DB Table CodeTable ------------------------------------------------------------------ I may well initially start out with a random set of ErroCodes. But if necessary I will re-arrange them into recognisable groups. - As indicated earlier a class like DateAndTime or (1) Customer Edit holds a messageTable (1a), resulting from ErrorsFound. - (2) The Customer ISAM File class reports on file-status codes good or bad. If 'bad' it searches (2a). (2a) is a full list of ANSI file-status codes plus a specific Micro Focus set where file-status-1 = "9" - Similarly (3) the Customer DBTable - if SQLSTATE = "00000" continue else do an error routine going to (3a). - In each of (1a), (2a) and (3a) there is a search for the appropriate error-message Now relating to the re-grouping of ErroCodes I can add the following additional Level 88s, (but to ensure it works I must also ensure message literals are in the same sequence in (1a) ):- 01 ErrorCode pic x(4) comp-5. 05 NoErrorsFound value 0. 05 Error-aaaa value 1. 05 Error-bbbb value 2. 05 Error-ccc etc 05 ....... 05 ....... 05 Error-Info value 1 thru 2. 05 Error-Warning value 3 thru 7. 05 Error-Critical value 8 thru 13. 05 ValidErrorCodes value 1 thru 99. *> if you think this necessary Without checking I think I only use ErrorCritical for COBOL file-status and SQLError. In the case of either if you hit the DELETE button in a dialog - no automatic deletion, I come back with - Warning Icon, "Are you sure you want to delete this record (or row) ?" <Yes> <No>. Within the Business Logic, assuming I have generated a CSV file from a COBOL ISAM I tend to give back a more detailed message - Info Icon, " Filepathname-isam - has been written successfully to Filepathname-csv", followed by <OK> button. I'm telling the user exactly where the csv is stored (which folder). MyMessages. I'm not being 'the big I AM' calling it my Messages, it reads :- -------------------------------------------------------------- Class-Control. *> M/F Support Classes : CharacterArray is class "chararry" MessageBox is class "msgbox" *> Your Classes : MyMessages is class "mymessages" ---------------------------------------------------------------- Four Parameters :- - Type choice of 4 - I called them Messagebox Icons above - Message Buttons - choice of 6 combinations - MessageTitle - The Messagebox title bar held as a displayable object - MessageObject - The STRINGed message built primarily from the message literals also held as a displayable object. These parameters are passed to MyMessages which uses them to invoke methods for the four elements above in the M/F support class Messagebox. Now I know this has damn all to do with Level 78s directly, but with progressive design, (it didn't happen in five minutes !), I can use common classes, (components ?) to produce a messagebox for anything. > It is (IMHO) a matter of good system design to have as few items as > possible that would require the program to be recompiled. A > configuration file, or a file or database table for unrelated data > should hold these values. Don't disagree with your first sentence one bit. However I am somewhat unhappy with the second sentence. Bear in mind you and our good friend Robert Wagner are on a parallel course on this one. He observed from something that I wrote that given a multi-language situation, English/French/German, that the message literals should be in a separate file/database. Most certainly it can be done. And you two having thought it through would make it work ! I had a bad experience before the switch to using Windows and VISOC. In DOS mode with M/F I was using the M/F SCREEN SECTION with its attributes plus colouring. Didn't take too long to figure out and I stored the details in file - I've completely forgotten specifics). I got a corrupted ISAM file message. Yes I did have a backup, but (again I've forgotten) couldn't get that back again either ! So I never used that concept again; then did the switch to VISOC anyway, leading on to Net Express. I've never used M/F's Exception handler - so I had to go back and check. It is specifically for OO. "On Exception do this .... ". Briefly add your ErrorCode to an offset value and it retrieves your literal from a TEXT file, i.e. Sequential". I thought that was really peculiar - random thinking about a week later, I had it figured. It's bloody difficult to corrupt a text file ! You can accidentally delete it, but if you have a backup, you are still kosher. Now here's the bit that really bothers me. Neither you nor I will be around to collect one another's money in twenty years - come to think of it, you might, but not me :-). I'll bet, start the following to-day and it will definitely be a balls-up well within 10 years, or less. Your approach works for you and Robert and at this time I bet he is squeezing his buddies he is working with to follow suit. Anyway, yours and his approach in a medium sized shop or bigger. And remember we are dealing with a mixed bag when it comes to human beings. Mr. X proposes something like you describe, some say 'Yes' others 'No'; but his boss likes it; grumble, grumble, grumble. Mr. X creates the system but doesn't want to be involved on day-to-day control, so young Joey is given that task as A, B or C trot across for some error literals or whatever. Say 2 years later Mr. X moves on for more money but little Joey hangs around. Mr. X1 either from internally or externally takes over the role of Mr. X. Joey is still there, so no sweat. Eventually little Joey thinks, "I ain't no damn clerk, I wanna be a real programmer", so he moves on. Mr. X1 doesn't see this particular function as being terribly relevant so doesn't pay too much attention to it, but uses a new kid Dickie to do the donkey work. Dickie wasn't in on the original design, but it probably wasn't complex, but with no pride in the job lets slip through some duplicate requests. Within about four years although it works it will be one unholy mess, (this is the analyst in me reacting). Research reveals perhaps some duplicates and some which have never been used. Without a background history you are a brave person who says "delete those unnecessary records". I've related this one before let me repeat it. Alan J with me at Denbenhams in Taunton had an old buddy of his visit. This chappie had worked at Westland Helicopters - which I knew of, it was in a valley below our first home we owned in Yeovil, Somerset. Westland eventually became part of Sikorsky. Anyway as an aside the topic of numbering came up, where this man related that Westland Part #'s had to be translated into NATO Part #'s (or perhaps vice versa). "How did that work ?", I asked. "Christ knows, the meaning was lost in antiquity", was his reply. > In my systems that go back up to thirty years even the file-status > values are in a data table, with descriptions, which makes it easy to > adjust for the different compilers. OpenCobol 'Record Locked' is '51'. > Any particular reason you picked on Record Locked = 51, or was that just a random example ? My (2a) above contains three references to Record Locking :- 05 pic x(L2) value "38Open on file previously LOCKED ". 05 pic x(L3) value "065File locked ". 05 pic x(L3) value "068Record locked ". The first is Standard ANSI codes and the other two are M/F's use of the authorized Vendor's extension where file-status-1 = "9". Knowing it was you thought I'd better check on your famous/infamous, (depending upon one's point of view :-), Open Extend Error Code - I do have a link into their current Knowledge Base, I've got the URL in 2(a) above - but it's one of those crazy 128 character URLs. I Bookmarked it when I first saw it, but can't get at the damn thing now because you have to go through a Left Pane Treeview by product, then down through sub-elements etc. All I've got in (2a) above is a 'whisper' searching the source on "Extend" :- 05 pic x(L2) value "35Open IO/INPUT/EXTEND non-optional". If you want to know what I've got for the following :- 05 pic x(L2) value "00No further information ". 05 pic x(L3) value "000No further information ". First is ANSI and second is file-status-1 = "9" Go figure :-) Jimmy, Calgary AB
From: Richard on 17 Feb 2010 14:01
On Feb 17, 6:59 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> wrote: > > 01 ErrorCode pic x(4) comp-5 *> or pic 9(03). > 88 NoErrors value 0. > 88 NameMissing value 1. > 88 AddressMissing value 2. > 88 ... > 88 LastCurrently value 35. > 88 ValidErrorCode value 0 thru 35. *> or 1 thru 35, depending upon > *> your coding style I dislike 88 levels. The problem that I find is that if I wanted to find all references to where 'ErrorCode' is used I have to search for all the various names using it. > 78 NM value 35. *> NM = Number of Messages > 78 ML value 30. *> ML = Message Length > 01 MessageTable. > 05 pic x(ML) value "Customer name is missing". > 05 pic x(ML) value "Address missing for Customer". > 05....... > 05 ....... > > 01 Filler redefines MessageTable. > 05 ErrorMessage pic x(ML) occurs NM. You can be _much_ cleverer that that: 78 ML VALUE 30. 01 MessageTable. 05 pic x(ML) value "Customer name is missing". 05 pic x(ML) value "Address missing for Customer". 05....... 05 ....... 01 MX REDEFINES MessageTable PIC X. 78 MN VALUE LENGTH OF MessageTable / ML. 01 Filler redefines MessageTable. 05 ErrorMessage pic x(ML) occurs NM. The MX redefine is required to complete the MessageTable definition so that its length can be used. However I don't use 78s, not even for this. |