Acucobol Error 98.13
in [Cobol]
|
From: Gio on 24 May 2010 11:05 Hi there, is anyone facing the error 98.13 ? Any clue about it ? Thanks for your comments Giovanni
From: Mattc on 25 May 2010 08:39 On May 24, 11:05 am, Gio <giovanni_dim...(a)virgilio.it> wrote: > Hi there, > is anyone facing the error 98.13 ? > Any clue about it ? > > Thanks for your comments > > Giovanni Giovanni: WHich version of Acu is giving you the error?
From: Gio on 25 May 2010 09:50 On May 25, 2:39 pm, Mattc <mpcso...(a)gmail.com> wrote: > On May 24, 11:05 am, Gio <giovanni_dim...(a)virgilio.it> wrote: > > > Hi there, > > is anyone facing the error 98.13 ? > > Any clue about it ? > > > Thanks for your comments > > > Giovanni > > Giovanni: WHich version of Acu is giving you the error? I'm using ACUCOBOL 4.3 Thanks G
From: James J. Gavan on 25 May 2010 17:40 Gio wrote: > Hi there, > is anyone facing the error 98.13 ? > Any clue about it ? > > Thanks for your comments > > Giovanni That's a very vague question; also I don't know AcuCOBOL. Is it a file-status code you are getting on accessing COBOL files ? Assuming it is a file-status code. which is :- 01 FileStatus. 05 FileStatus-1 pic x(01). 05 FileStatus-2 pic x(01). When file-status 1 = "9" then file-status-2 is not defined by the COBOL Standard and the implementor (compiler vendor) is free to use the second character as they wish. In Micro Focus products there is a routine to translate the one character in file-status-2 to a three-digit code and get the accompanying literal for the error. (The M/F routine works and to my knowledge at least three developers have gone belly-up dreaming up their own conversion routines - their results were meaningless). Again, assuming file-status, this is a link to the total M/F file-status codes. http://kb.microfocus.com/display/1n/index.aspx?c=12&cpc=BTakh05i2p2gM801Slr08SHyX275E544jc&cid=2&cat=&catURL=&r=0.519614815711975 If you use the same KnowledgeBase to do a lookup on AcuCOBOL you might find a similar list. (If you have Acu on-line manuals they should contain a comprehensive description of their use of file-status codes). If your query is not about files - where do you get the 98.13 ? Stick my neck out : Again assuming the 98 is a file-status code, I'm going to take a guess as to what it might be. Under normal circumstances you shouldn't encounter file-status-1 with a value of '9' - i.e. if you are disciplined in your design approach. Here's a small sample of the Micro Focus extended codes :- 05 pic x(L3) value "023Illegal access mode for CLOSE ". 05 pic x(L3) value "024Disk input output error ". 05 pic x(L3) value "025Operating system error ". 05 pic x(L3) value "026Block i-o error ". 05 pic x(L3) value "027Device not available ". 05 pic x(L3) value "028No space on device ". 05 pic x(L3) value "029Attempt to delete opened file ". 05 pic x(L3) value "030File system is read only ". 05 pic x(L3) value "031Not owner of file ". 05 pic x(L3) value "032Too many idx files/no such procs". 05 pic x(L3) value "033Physical i-o error ". 05 pic x(L3) value "034Incorrect mode or file descriptr". 05 pic x(L3) value "035Accessing file without permiss'n". 05 pic x(L3) value "036File already exists ". 05 pic x(L3) value "037File access denied ". 05 pic x(L3) value "038Disk not compatible ". 05 pic x(L3) value "039File not compatible ". 05 pic x(L3) value "040Language init not set correctly ". 05 pic x(L3) value "041Corrupt indexed file ". 05 pic x(L3) value "042Attempt to write on broken pipe ". 05 pic x(L3) value "043File info missing - Indexed File". OK, so twice in my career I hit the 039 above. Example 1 - I created an ISAM file and used a $set Directive to set Data Compression. Worked fine - about a year later I was testing the same application and got the '039' - couldn't even Open the file. Moved onto something else and I twigged it about two months later. Bearing in mind I already had data in the ISAM from the first stage, the failure occurred on the later attempt to access the file. My new version of accessing the file DIDN'T include the $set data compression etc... Had to fail - the file was initially set up and had data which was compressed and second time around I'm trying to access that file ignoring the compression factor. Example 2 : I create a file with say a record = 150 characters. Worked fine and I added data to that file. Quite some time later decided to alter the data record to say 155 characters, another field I required. Again didn't work. Initial file was created with 150 character data and second time around I'm asking for records with the new size of 155 characters. Jimmy, Calgary AB
From: Mattc on 26 May 2010 09:24 On May 25, 9:50 am, Gio <giovanni_dim...(a)virgilio.it> wrote: > On May 25, 2:39 pm, Mattc <mpcso...(a)gmail.com> wrote: > > > On May 24, 11:05 am, Gio <giovanni_dim...(a)virgilio.it> wrote: > > > > Hi there, > > > is anyone facing the error 98.13 ? > > > Any clue about it ? > > > > Thanks for your comments > > > > Giovanni > > > Giovanni: WHich version of Acu is giving you the error? > > I'm using ACUCOBOL 4.3 > Thanks > > G Giovanni: First, that is a really old version of Acu, but the Vision file system is pretty solid so I guess that doesn't matter. I am sure you have tried rebuilding the file using Vutil32 -rebuild, which should correct any normal error 98 condition; and if that does not correct the file then either you have a hard disk error in a sector occupied by the file or, you can try using Vutil32 -unload to create a sequential file and then rebuild it with a program of your own in another area of your drive.
|
Next
|
Last
Pages: 1 2 Prev: Expression evaluator using Interpreter Pattern Next: Suppressing Cobol print messages |