Level 78
in [Cobol]
|
Prev: all
Next: Open Cobol is free and standard.
From: James J. Gavan on 17 Feb 2010 21:47 Richard wrote: > On Feb 17, 6:59 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> wrote: > > >>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 :- > > > OpenCOBOL file status value for record locked is '51'. > >> 05 pic x(L2) value "38Open on file previously LOCKED ". > > > That refers to trying to reopen a file in a run unit when previously > it had been "CLOSE file WITH LOCK". > >> 05 pic x(L3) value "065File locked ". > > Another program has the file open in exclusive mode. Or in DOS/Windows > something else has opened the file. One of the many things that I > disliked about DOS and Windows and find nice in Unix/Linux is that the > latter don't prevent me from accessing a file that is open and > running. I can watch files as they are being created by other > programs, for example using tail or more. Under Windows if I am > examining a file the COBOL program will give this error when it tries > to open it. > > >> 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". > > > And Fujitsu has 93 for file locked and 99 for record locked. > > >>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". > > > You get a 35 error status when a file does not exist and is not > specified OPTIONAL explicitly or implicitly (a MF compiler option). If > is is OPTIONAL you get a 05 and it is created (IO and EXTEND) or acts > as if there was a zero length file (INPUT). > Given the sequence of events, now it makes sense. I paraphrased the Error 05, (from the M/F manuals), to read :- 05 pic x(L2) value "05Optional file not present ". However, each time you broached this subject I always used to think, under what circumstances would you want to EXTEND a Sequential File to add additional records. Given that PC systems tend to be inter-active, per transaction, i.e. fill in a dialog and then WRITE or REWRITE, (obviously to an ISAM), I've never done it, and have never thought of it as a possibility. Are you in effect working in a semi batch-processing mode, (perhaps in Linus/Unix, which you mentioned). So some sort of example where you use it ? Jimmy, Calgary AB ----------------------------------------------------- Completely Off-topic note for you two in the Antipodes : The 'Great Escape", the factual (Canadian), version, not the movie version. Fictional or not, Steve McQueen would not have been riding his motorcycle, (and in the movie it was him, not a double), in summer against a glorious backdrop of meadowland and magnificent views of mountains. The Escape was in March 1944, in similar conditions to where I'm writing from now, with snow on the ground, and the escapees were suffering from malnutrition, which meant very few would have been successful anyway. Hitler raged and wanted them ALL executed. Surprisingly the former chicken farmer, Heinrich Himmler suggested a lesser number - perhaps he liked round figures - some 50 were shot. (That's the way the Canadian TV documentary puts it, although just Webbing to get the date March 1944, Goering and senior Luftwaffe officers did the initial pleading with Hitler). An SS General was chosen to select the candidates. Naturally, apart from the British ring-leaders he looked for Jewish or Slavic names - "Der Untermensch". As the list rolled by quickly on the TV screen, either Flying Officer or Flight Lieutenant Pohl from the RNZAF had been chosen. The actual executions appear to have been done by the Gestapo, (from Web sources), paralleling the scenes in the movie where the prisoners were let out of trucks supposedly to allow them to urinate - and then shot. In the movie James Garner played the part of a real-life flight lieutenant in the RCAF. He was nicknamed 'Scrounger'; organised the booty they needed for the Escape. That man died here in Canada, about two years ago. One of these days, when I find it again, I'll send you two a photo postcard, which I specifically got for you. The Commonwealth Air Training Programme. Across Canada the countryside was ideal for training aircrews and particularly here in Alberta. Some trainee navigator might ask, "Where's south ?". "Just keep following that road kid, (McLeod Trail) and you'll make it to the Montana border". Many nationalities trained. Our neighbour in Portsmouth asked my brother back in '65, "Where are you emigrating to in Canada ?". "Calgary", David replied. A real deep groan from the questioner. He had done his training in an area on the then outskirts of Calgary now occupied by Mount Royal College - only recently designated Mount Royal University. Back then they had to walk all the way to the downtown core, to get a drink ! There's a pit-stop on the way south of us about 2 hours, called Nanton. The community set up a Lancaster war museum. They have a refurbished Lancaster bomber, but it never saw action; used for training. Nevertheless an interesting site to visit and squeeze through the small pathway (can't think of the correct aeronautical word/phrase), moving from the back (rear gunner) up to the pilot's seat at the front. And with maps, diagrams, models, they record the history of the RCAF's participation in Bomber Command. The squadrons would have been based in East Anglia - closest to Germany. The photo - High River, about an hour south. Pleasant enough with 1900-ish houses, but I don't care for the dull scenery around - not clear views of the Rockies. Some adventurous artists tarted up some buildings which had period plain red brick walls by painting murals, depicting several scenes, one I recall a round-up of cattle, and the point of this - a hangar in the background with a large group of newly qualified pilots in air force blue being presented with their wings by a senior office - part of above Training Programme. Next to it is a small plaque, can't remember if there are more than the four I indicate, but larger bronze versions of cap badges, dedicated to the RAF, RAAF, RCAF and RNZAF. That's what I have a photo of.
From: Richard on 17 Feb 2010 22:39 On Feb 18, 3:47 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> wrote: > Richard wrote: > > On Feb 17, 6:59 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> wrote: > > >>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 :- > > > OpenCOBOL file status value for record locked is '51'. > > >> 05 pic x(L2) value "38Open on file previously LOCKED ". > > > That refers to trying to reopen a file in a run unit when previously > > it had been "CLOSE file WITH LOCK". > > >> 05 pic x(L3) value "065File locked ". > > > Another program has the file open in exclusive mode. Or in DOS/Windows > > something else has opened the file. One of the many things that I > > disliked about DOS and Windows and find nice in Unix/Linux is that the > > latter don't prevent me from accessing a file that is open and > > running. I can watch files as they are being created by other > > programs, for example using tail or more. Under Windows if I am > > examining a file the COBOL program will give this error when it tries > > to open it. > > >> 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". > > > And Fujitsu has 93 for file locked and 99 for record locked. > > >>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". > > > You get a 35 error status when a file does not exist and is not > > specified OPTIONAL explicitly or implicitly (a MF compiler option). If > > is is OPTIONAL you get a 05 and it is created (IO and EXTEND) or acts > > as if there was a zero length file (INPUT). > > Given the sequence of events, now it makes sense. I paraphrased the > Error 05, (from the M/F manuals), to read :- > > 05 pic x(L2) value "05Optional file not present ". > > However, each time you broached this subject I always used to think, > under what circumstances would you want to EXTEND a Sequential File to > add additional records. Given that PC systems tend to be inter-active, > per transaction, i.e. fill in a dialog and then WRITE or REWRITE, > (obviously to an ISAM), I've never done it, and have never thought of it > as a possibility. Are you in effect working in a semi batch-processing > mode, (perhaps in Linus/Unix, which you mentioned). > > So some sort of example where you use it ? A Log file, an Audit file, any number of files that don't need to be keyed and yet have a sequence, usually time. These may be LINE SEQUENTIAL, especially the system log file recording system login/logouts, file exceptions, backups, file edits, all sorts of stuff. Then when the user claims 'I just did xx' I can look at the log and say: "but at time hh:mm you did this".
From: James J. Gavan on 17 Feb 2010 23:00 Clark F Morris wrote: > On Thu, 18 Feb 2010 11:29:14 +1300, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> wrote: > > >>Richard wrote: >> >>>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. >> >>This is why I define the base as "filler"... It reminds me NOT to search for >>it. Instead I would search for where a condition gets SET... >> >>The point is that the 88 is not about the storage it is attached to; it is >>about a condition being true. > > > While I have used 88 levels in that manner, there is a lot to be said > for the approach taken by one vendor where they had a list of > constants - 05 RECORD-NOT-FOUND PIC XX VALUE '23'. (I may be > recalling the value incorrectly and the vendor had similar fields for > all of the status code values correctly coded). Then the test was IF > FILE-A-STATUS-CODE = RECORD-NOT-FOUND etc.. This is both readable and > easy to check for where FILE-A-STATUS-CODE is referenced. > That looks like a good approach to me Clark, just so long as it is provided by the vendor. Haven't thought it through; the above s fine to get the RECORD-NOT-FOUND, but what about RECORD-FOUND ? I do a double whammy with a copy file holding result codes for COBOL Files and SQLErrors - it's latter day name WHICH became SqlResult.cpy when I moved from COBOL files to DB :- *>-------------------------------------------------------------- Method-id. "readRecord". *>-------------------------------------------------------------- 01 ls-Size pic x(4) comp-5. Linkage section. 01 lnk-PrimeKey object reference. 01 lnk-ReturnValues. copy "\copylib\SqlResult.cpy" replacing ==(tag)== by ==05 lnk==. 05 lnk-RecordObject object reference. Procedure Division using lnk-PrimeKey returning lnk-ReturnValues. initialize lnk-SqlResult invoke lnk-PrimeKey "SizeInBytes" returning ls-size if ls-Size <> ws-KeySize move "KS" to ws-fileStatus *> KS = 'Key Size': Dummy file-status *> to generate errorMessage set FileError to true ----------> into SqlResult above invoke self "FileErrors" EXIT METHOD End-if invoke lnk-PrimeKey "GetValueWithSize" using ls-Size returning Data-PrimeKey Read Data-File key is Data-PrimeKey invalid key set RecNotFound to true ------> into SqlResult not invalid key *> This Returns lnk-SqlResult = zeroes. *> If invoked by method "deleteRecord" the zeroes *> signal 'Record Found' invoke CharacterArray "withLengthValue" using ws-RecordSize, Data-Record returning lnk-RecordObject End-Read if ws-fileStatus = "00" or "23" continue else set FileError to true ------> into SqlResult invoke self "FileErrors" End-if End Method "readRecord". *>-------------------------------------------------------------- Initially I copy/pasted the above without the test for PrimeKey size, thinking it would confuse. However this particular method illustrates how both IN-coming and OUT-going objects can be created. In a string version, pic x(??) of sending/receiving objects, and particularly if a file class which can be used for variable length records, it overcomes the size problem, taking a receiving example :- 01 lnk-Record. 05 pic x occurs from 1 to 1,000 depending on MaxRecordSize. Procedure Division using lnk-Record. The above can be done but it is clumsy; also it has to be carefully thought through. The CharacterArray conversions : - Sender - you get the length for the sending record to create the object - Receiving - because the object knows its own length, (one of its properties or attributes), by size you can unwrap it. If designed well it shouldn't present problems. But using (X)treme (P)rogramming, just like I've checked the incoming KeySize in this particular example, you can do exactly the same for the whole record. Jimmy, Calgary AB
From: James J. Gavan on 18 Feb 2010 01:42 Richard wrote: > On Feb 18, 3:47 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> wrote: > >>Richard wrote: >> >>>On Feb 17, 6:59 pm, "James J. Gavan" <jgavandeletet...(a)shaw.ca> wrote: >> >>>>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 :- >> >>>OpenCOBOL file status value for record locked is '51'. >> >>>> 05 pic x(L2) value "38Open on file previously LOCKED ". >> >>>That refers to trying to reopen a file in a run unit when previously >>>it had been "CLOSE file WITH LOCK". >> >>>> 05 pic x(L3) value "065File locked ". >> >>>Another program has the file open in exclusive mode. Or in DOS/Windows >>>something else has opened the file. One of the many things that I >>>disliked about DOS and Windows and find nice in Unix/Linux is that the >>>latter don't prevent me from accessing a file that is open and >>>running. I can watch files as they are being created by other >>>programs, for example using tail or more. Under Windows if I am >>>examining a file the COBOL program will give this error when it tries >>>to open it. >> >>>> 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". >> >>>And Fujitsu has 93 for file locked and 99 for record locked. >> >>>>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". >> >>>You get a 35 error status when a file does not exist and is not >>>specified OPTIONAL explicitly or implicitly (a MF compiler option). If >>>is is OPTIONAL you get a 05 and it is created (IO and EXTEND) or acts >>>as if there was a zero length file (INPUT). >> >>Given the sequence of events, now it makes sense. I paraphrased the >>Error 05, (from the M/F manuals), to read :- >> >> 05 pic x(L2) value "05Optional file not present ". >> >>However, each time you broached this subject I always used to think, >>under what circumstances would you want to EXTEND a Sequential File to >>add additional records. Given that PC systems tend to be inter-active, >>per transaction, i.e. fill in a dialog and then WRITE or REWRITE, >>(obviously to an ISAM), I've never done it, and have never thought of it >>as a possibility. Are you in effect working in a semi batch-processing >>mode, (perhaps in Linus/Unix, which you mentioned). >> >>So some sort of example where you use it ? > > > A Log file, an Audit file, any number of files that don't need to be > keyed and yet have a sequence, usually time. > > These may be LINE SEQUENTIAL, especially the system log file recording > system login/logouts, file exceptions, backups, file edits, all sorts > of stuff. > > Then when the user claims 'I just did xx' I can look at the log and > say: "but at time hh:mm you did this". OK Richard fair enough, and can see purpose. But I would have probably thought of using a RELATIVE file, (the next Relative record would be by ws-RelativeKey giving your time-sequence, except of course you can independently of COBOL open a text file and search. Sure clarifies why and how you are doing it this way. No quibble at all. Your solution sure is a belt and braces approach. Methinks you've got either some very aggressive clients or some real dumb ones. My German 'friend' for whom I did the Corrosion Testing system, nice man, but oh what a bloody PERFECTIONIST : EXAMPLE 1 - Back in DOS days when we used a screen painter with RM/COBOL the Master Menu was no more than one screen filled with numbered menu options; in the Edit group - (1) Customer Names (2) Facility Names (3) Systems (4) Vessels (5) Items etc.... Working from home I had occasion to go over to his office, no doubt with some new changes, and accessed his computers. Immediately taken aback, couldn't find 'Systems'. Using the screen painter he had gone in and changed it to 'Services' - same difference. EXAMPLE 2 - I think this one has to be the real cat's Meow. Over my shoulder he is looking at some new screen, peering and pointing at it; the comment was "Can you move that down about half an inch ?". Gimme a break ! But for the fact I desperately needed the money I would have told him to, "Stick your job where the sun don't shine !" That pimp/head-hunter for California - I tell yer $33 per hour is better than $zero per hour :-). BTW should he read this, no point in contacting me I haven't got a passport to get across the 49th. Jimmy, Calgary AB
From: Pete Dashwood on 18 Feb 2010 05:18
Clark F Morris wrote: > On Thu, 18 Feb 2010 11:29:14 +1300, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> wrote: > >> Richard wrote: >>> 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. >> >> This is why I define the base as "filler"... It reminds me NOT to >> search for it. Instead I would search for where a condition gets >> SET... >> >> The point is that the 88 is not about the storage it is attached to; >> it is about a condition being true. > > While I have used 88 levels in that manner, there is a lot to be said > for the approach taken by one vendor where they had a list of > constants - 05 RECORD-NOT-FOUND PIC XX VALUE '23'. (I may be > recalling the value incorrectly and the vendor had similar fields for > all of the status code values correctly coded). Then the test was IF > FILE-A-STATUS-CODE = RECORD-NOT-FOUND etc.. This is both readable and > easy to check for where FILE-A-STATUS-CODE is referenced. Sure. For me it is unwieldy, but that is a personal opinion and many will disagree. I would use: IF RECORD-NOT-FOUND... (Actually, I wouldn't, but that's another story...Ithink things like status codes and return codes are a different case, because they are set outside the program's control, and can be addressed differently, but it is again, a personal opinion and choice. As I don't write much COBOL these days, I see no popint in arguing it.) Since I saw this discussion I have tried to recall the last time I was searching for a field with 88 levels on it. I adopted the convention of using filler for them about 20 years ago so it has been a while... I honestly can't remember ever doing that. Not even with things like first-time and finish flags. To me, the conditions are what matters Pete. -- "I used to write COBOL...now I can do anything." |