Using UniData Multifiles from SB+

[Tom Pellitieri]

Is there any documentation around on how to use UniData Multifiles effectively with SB+?

For those unfamiliary with Multifiles - UniData allows for a single dictionary to be associated with several data sets/hashed files.  The "default" data set name matches the dictionary name, but others can be selected "on the fly" by specifying the subfile.  The system creates the normal D_FILENAME dictionary file, plus a folder FILENAME, which contains multiple hashed files (e.g., FILENAME, FILEPAST, FILENEXT).  You specify the subfile at TCL as needed (e.g., SORT FILENAME vs. SORT FILENAME,FILEPAST).

I maintain a price update file with a separate data portion for each vendor (currently 40 vendors).  This allows me to track when vendors drop products from their price lists.  I'd like to create a screen that would allow someone to look up an entry for a particular vendor without having to create a separate version for each one.  The screens, select processes, &c., would all need to point to the selected data portion.

Is this functionality "built in" to SB+ somewhere that I just haven't used, or am I trying to do something outside the design specs?  I know you can specify a different data file than the dictionary, but can this be done "on the fly"?  Any thoughts?

--Tom

[precisonline]

Easily done.  The Data File (if diff) can be a parenthetical SB+ expression.  So let's say you have a PRICE.INPUT file with a subfile for each vender:

PRICE.INPUT,000100
PRICE.INPUT,012334

If you know the vendor before the /PD.I is called you can pass this information into the PD.I in @PARAM in which case your data file expression would be something like this:

('PRICE.INPUT,' : @PARAM)

Alternatively, if you prompt for the vendor on the screen itself (i.e. after the main file has already been opened) you can simply change @MAINFILE and then OPEN @MAINFILE TO 0 in a paragraph (which updates @F.FILE) and achieve much of the same objective.

[precisonline]

Clarification: The Data File (if diff) can be a parenthetical expression everywhere it is found, PD.I, PD.S, PD.O, PD.R... everywhere.  So if you were to throw your vendor code into a @PARMS(..) element, it'd be no big deal to use that information in an expression that calculates the ML file name.

[Tom Pellitieri]

Thanks, Kevin - now I just need to find a "safe" common variable that won't get clobbered by other standard (Prelude) processes - @PARAM won't hold

--Tom

[precisonline]

@USERDATA(5) is usually pretty good.  And you could also do a passthrough wrapper around a PARMS(..) element, like this:

LOCAL L.HOLD.P36
*
L.HOLD.P36 = @PARMS(36)
EXEC @PARAM
@PARMS(36) = L.HOLD.P36

...then the process name (as passed in the parameter) could do whatever you want with @PARMS(36) and it shouldn't have any impact on anything else.  Of course, pick whichever @PARMS(..) element works best.