Ref.Topic "Save SELECT list with alternate key?"

I tried FSELECT but SIZELOCK gives me an error at line 100

It looks like the dosHandle is null so it errors.

As far as the code that gets the dos file name is beyond me

1,\42FD\ hmmm

I'm Part time Programmer.. self taught.. bla bla bla :)

Thanks

Never heard of FSELECT.

Can you tell us what version of Arev, and if you have a special version?

Can you look at the VOC FSELECT and tell use what is on each line (in the EDIT?

Dave

Dave

It's one of the utility programs included in the Developer's Utility disks available in the download section.

I haven't looked at the code but I suspect that somewhere along the way that file handles or how file handles are cached in memory were changed as the old trick of stripping of MFSes from the file handle stopped working at some point too.

As per Warren its on the Developer's Utility disk 5

I am running 3.12 of Arev.

Warren I think your right. Im just not sure what the SIZELOCK sub is trying to do. Its being called by FSELECT and the code is about 1.625" over my head.

Thanks

I haven't looked at the utility in question, but I can make a guess about what it's doing.

Sizelock controls whether a file can be resized or not. A value of 0 means that it is allowed to grow or shrink. A value of 1 means it is allowed to grow but not allowed to shrink. A value over 1 (always even) means that it cannot grow or shrink.

When you do a select on a file, you want to ensure that records don't move around while you're resolving the request. You do that by changing the sizelock to 2 or more. When the select is finished, the sizelock is decremented again.

The SELECT command does this sizelock control for you. However, if you're going to write your own utility to do something akin to a SELECT, you may have to do the sizelock operation yourself. I'll bet that's what's going on.

As per Warren its on the Developer's Utility disk 5

I am running 3.12 of Arev.

Warren I think your right. Im just not sure what the SIZELOCK sub is trying to do. Its being called by FSELECT and the code is about 1.625" over my head.

Thanks

I looked at the program. The explanation is right there:

/*

 Since we are doing a latent select through the file, we need to increase

 the sizelock by two to prevent hashing.  See the sizelock utility on the

 Developer utility disk #5 for more information on how to use this

 subroutine

*/

You can remedy this by changing the latent select to a normal select and then omitting the sizelock calls.

Well I tried it at home under v2.12 and it worked fine. I haven't had a chance to try it under v3.12 to see what's going on with the file handles.

If you're running it on a non-shared system just bypass the call to sizelock and not worry about it.

Yes, and back to what I orig. said.

FSELECT calls SIZELOCK which error at line 100

its somewhere between line 76 - 86 in SIZELOCK

dosHandle doesnt get a value (i think dosHandle should be assigned the dos path and filename. but like i said im not sure whats happening here)

I know enough to bang out simple code but as far as the file handles or how file handles are cached in memory.. now were are about 24" over my head.. :)

:) well its on a network and being shared..

I'm still trying to figure out how the code is trying to get the dos file name (if thats whats going on)

fh=handle-1,BACKTOVM this code just get the Arev file name not the dos file name. But thats assuming things I dont understand :)

btw thanks for you input

And now I find this gem of info

http://www.revelation.com/discuss.nsf/7a591c01171830eb8525652b0083c06b/1FC6DB069396C6B98525676E002F514F?OpenDocument

Im getting closer.. I think :)

It's likely the utility was written before the driver you're using was available. The NLM, for example, uses a different file handle structure than a plain jane driver does. That's probably why you're not getting a good handle. You can see what a handle looks like yourself by:

Perform some sort of access to the file (listing it is sufficient)

Then type:

EDIT SYSTABLES filename

The handle appears on the 5th line. The Sizelock routine is parsing this value to try to access the DOS file directly. Depending upon the driver you may not be able to do so anyway (REVPARAM may be set preventing this, for example). You can probably set the sizelock using a BFS call instead, but you'd have to research how. I've never done it because I've not had the need.

In SIZELOCK replace line 76-81

   fh=handle-1,BACKTOVM
   if fh=S' then
       handle-1, -2='
       fh=handle-1,BACKTOVM
   end

With

   lkcnt=count(handle,'.LK')
   lkpos=index(handle,'.LK',lkcnt)
   fh=handlelkpos+2,BACKTOVM

This makes the bold assumption that the string ".LK" is not used in volume or MFS names but we'll cross that bridge if it happens.

That code would not work with the handle structure of the environment I'm using right now. Our system uses the NLM. The NLM file handle includes FFFFFF before the path to the LK file. You'd need to parse it out.

Why not instead get the filename by getting the path from the volume record and appending the filename be reading the REVMEDIA record? That would work unless access to the DOS file were restricted (not unlikely), in which case osbwriting by whatever means would fail even if getting a good handle succeeds.

Victor

Because you have to override the sysprog password protection on REVMEDIA files. I prefer not to reveal these methods which will compromise what little security there is.

However since the genie was let out of the bottle early use what ever method and reveal whatever internals of ARev you want.

Why don't you just modify the code to compensate for the additional bytes from the NLM?

I just tested this on a client system running Netware 6.0 and the NLM 5.0 and it works as advertised.

The relevant section of thefile handle after the @VM consists of char(13) followed by 6 bytes followed by "FFFFFF" by the path and DOS file name. Stripping off these first 13 bytes gives you the fully qualified path name which is what these statements do:

     n=seq(handle1,1)

     dosName=handlen+1,9999

You tell me why it doesn't work on your Netware NLM system.

File access is through the REVELATION user. The DOS files are unavailable for update by the rif raf. If you're messing with sizelock, you should also have appropriate locking in place. Do you?

Anyway, it's not my problem to work around. I don't have the need. I was just pointing out potential pitfalls. What the best solution is probably depends on the intended audience.

Thanks for everyones help

I fixed (per Warren info) dosHandle section but now the section that does the reduction logic fails.

I get a W156 "" is an unrecognized word.

Figured it would be nice to have a way of inverting a key list but like doesn't look like its working..

Here is my tcl statement

FSELECT SALES_ORDER SETTING SALES_ITEM_NO WITH ORDER_DATE ] "07-15-08"

I am scrapping trying to use this.. tool/project

Again thanks.

If it were me, I'd probably just do something like this (off the cuff and not debugged):

OPEN 'LISTS' TO LISTS ELSE STOP;* Graceful code omitted

OPEN 'SALES_ORDER' TO HANDLE ELSE STOP

OPEN 'DICT.SALES_ORDER' TO @DICT ELSE STOP

PERFORM 'SELECT SALES_ORDER WITH ORDER_DATE ] "07-15-08"'

IF @REC.COUNT THEN

FINISHED='

LISTREC='

LISTNAME=SAVEDLISTNAME'

EXT='

LOOP

READNEXT @ID ELSE FINISHED=1

UNTIL FINISHED

READ @RECORD FROM HANDLE,@ID THEN

SALES_ITEM_NO={SALES_ITEM_NO}

LISTREC:=SALES_ITEM_NO:@FM

IF LEN(LISTREC) GT 30000 THEN

GOSUB PUT

END

END

REPEAT

GOSUB PUT

END

STOP

PUT:

IF EXT THEN

WRITE LISTREC ON LISTS,LISTNAME:'*':EXT

END ELSE

WRITE LISTREC ON LISTS,LISTNAME

EXT=1

END

EXT += 1

RETURN

Thanks Victor

I know my Select will only yield small number of hits so I just wrote it to put the new keys in a variable.

But I think I can mod that one to be more generic and then save it as hmmm FSELECT :)

View this thread on the forum...