Hash Files Using Directory Path

mnevotti · Post by **mnevotti** » Tue Jan 14, 2003 5:32 pm

Hi all,

We have a job that creates a type 30 hash file (dynamic) using the Account name. In the job control we do an Open with a repeat loop to read all the records from the hash file. This works with no problems.

We created another job that creates a hash file using the directory path instead of using the Account name. In the job control we changed the Open to OpenPath thinking that is all we needed to do to read from this hash file with the full path directory name. This doesn't work. In the Universe Basic manual for OpenPath is states that "the file must be a hashed UniVerse file or a directory (UniVerse types 1 and 19)". In the job, for the hash stage create file options, it doesn't show the UniVerse file types of 1 or 19 in the list.

Is there more we are missing to using the directory path and reading the hash file in the Job Control?

-Melinda

ray.wurlod · Post by **ray.wurlod** » Tue Jan 14, 2003 5:52 pm

OpenPath is the correct statement to use. Check that your pathname is correct, and use both the On Error and Else clauses to report any problems with the open, in particular the error code returned via the Status() function.
Type 1 and Type 19 files are not hashed file types, which is why they do not appear in the Hashed File stage's drop down list of file types.

chulett · Post by **chulett** » Wed Jan 15, 2003 9:35 am

We are using both ON ERROR and ELSE in the OPENPATH statement, and neither of the clauses trigger. A status() following the OPENPATH returns '30' as I would expect.

Something that may be of interest is we execute a 'SELECT' statement in the code after the open to log the number of rows in the hash. With a hash inside the project (using OPEN) I get the correct number, with this change to OPENPATH (and that's all we change in the code other than to specify the full pathname), the select returns -1. The first READNEXT we do takes the ELSE path as if it thinks the file is empty.

We've verified everything we can think of: pathname is correct, hash lives where and looks like I would expect it to, it has records in it that I can view thru the plugin and the code has been working fine for quite some time using 'normal' hash files. Thought the only change we'd need would be to change OPEN to OPENPATH, but something else must be needed or we're missing something obvious.

-craig

ray.wurlod · Post by **ray.wurlod** » Wed Jan 15, 2003 3:38 pm

Think a bug may have appeared. I'm on 5.1 on NT this week, and it works fine. What version/platform are you running?

chulett · Post by **chulett** » Wed Jan 15, 2003 3:43 pm

5.2r1 (r3?) on a Tru64 5.1 cluster. I've got 6.0r3 loaded on a test server, guess I'll give that a shot when I get a chance and see if it runs over there.

mnevotti · Post by **mnevotti** » Wed Jan 22, 2003 3:43 pm

Hi all,

Craig tried this under version 6.0r3 on our test server and he is still getting the same problem. So it doesn't appear to be a bug at least fixed in the 6.0 version.

Anyone got any other ideas to try?

-Melinda

ray.wurlod · Post by **ray.wurlod** » Wed Jan 22, 2003 4:35 pm

It's time to ask how you're creating the hashed file.
The error message suggests that what OpenPath is seeing is not able to be recognized as a hashed file.
Can you provide the command (or method) you are using to create the hashed file? If you're doing this through a DataStage job, can you provide the message from the job log that reports that (and how) the hashed file is created?

Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518

chulett · Post by **chulett** » Wed Jan 22, 2003 4:53 pm

We just checked off the 'create' option in the Hash Stage, which generated this when it ran:

Creating File hashtest, Executing Command = mkdbfile [full path]/hashtest 30 1 4 20 50 80 1628

A status() call after the OpenPath returns a '30' as expected.

ray.wurlod · Post by **ray.wurlod** » Wed Jan 22, 2003 11:22 pm

Status() after a successful Open or OpenPath statement returns the file type (Type 30 = DYNAMIC), while InMat() returns the file's current modulus (number of groups).
This is one case where a non-zero Status() value is not indicative of error.
If the OpenPath statement executes its THEN clause, then the file is opened successfully.
So I return to Melinda's original assertion "this doesn't work". On what basis do you make this statement?

Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518

chulett · Post by **chulett** » Thu Jan 23, 2003 7:54 am

I recognize what Status() should return, hence the statement that it "returns a '30' as expected", indicating a dynamic hash. [:)] What's happening is that, according to everything we see, the hash *is* being opened successfully. Neither the ELSE nor the ON ERROR clause triggers on the OpenPath.

The "doesn't work" part is the fact that we can't subsequently *read* from the hash. Executing a select to get the total row count returns a '-1' instead of a true count, and the first READNEXT we issue fails as well. To me it would normally mean the hash was empty, but it has 73 records that view rather nicely via the Hash Stage.

In the meantime, we've opened a case with Ascential support. I'll let you know if anything comes of that.

-craig

ray.wurlod · Post by **ray.wurlod** » Thu Jan 23, 2003 4:53 pm

The Status() value of -1 on select indicates that an error has occurred. How are you doing the Select? Is it the BASIC statement (Select), in which you can specify an ON ERROR clause to see what's happening? Have you creamed the file variable between the Open and the Select? Would you like me to review the code in question?

Ray Wurlod
Education and Consulting Services
ABN 57 092 448 518

mnevotti · Post by **mnevotti** » Thu Jan 23, 2003 5:11 pm

Ascential Tech support has reproduced the problem on their end and is investigating it. We can let everyone know what they find.

-Melinda