Accessing DCL/System Symbols from TPU Programs

[dan radke]

This is a restatement of my question - I have a bunch of TPU programs I inherited that have "welded" directory paths that I wish to make environmentally controllable with DCL/System symbols. How can one pass symbols into TPU?

[Verne Britton]

how about defining X: before entering TPU and then inside, always use X:file.dat syntax?

... as in

define X dka200:[top.next.bottom]


Verne

[Wim Van den Wyngaert]

Study the CALL_USER feature. You need to write/get a small program that gets the symbol and returns it as a string.

http://h71000.www7.hp.com/doc/73final/documentation/pdf/OVMS_73_DEC_TPU_REF.PDF

Or do a sh symb to a buffer and use a loop to find the one you are looking for.

Wim (never used it)

[Steven Schweda]

> This is a restatement of my question [...]

Yes, it is, but it may not be an improvement.

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1262910

First, what does "DCL/System symbols" mean to
you?

What, exactly are you trying to do? As
usual, it might help if you explained the
actual problem, instead of asking how to
implement what may be a suboptimal solution
to it.

Previous suggestions involving logical names
still sound good to me, but I have only your
vague description of '"welded" directory
paths' to work from.

[Mark Katz]

If I understand correctly from your previous question that you are talking about custom TPU section files, and not the EVE editor, then you have many options available to you.

The easiest is to use the command qualifiers such as /OUTPUT, /JOURNAL, etc. for your own purposes rather than for the purposes originally intended for them. Many TPU users don't realize that the /JOURNAL qualifier only controls journaling if the TPU code in the section file checks for and processes the qualifier. The EVE section file does this. It's likely that your custom section files don't do journaling, so you can use the journal file (or the /OUTPUT file or the input file parameter) for whatever you want.

For example, let's say your program needs to read in a user-specified parameter file which contains parameters in whatever format you desire. You can do the following:

$EDIT /TPU /SECTION=wherever:mysection.tpu -
/JOURNAL=mydir:myparameters.dat

and in the tpu code in mysection.tpu you can do:

param_file := get_info(command_line,"journal_file");

Then, if you want there to be a default for the paramater file or part of the paramter file filespec you can do:

param_file :=
file_parse(param_file,'sys$disk:[]parameters.dat;0');

Then you can create a buffer and read in the file:

param_buffer := create_buffer("PARAMS",param_file);

With regard to your original question, you can put any valid file spec into the /JOURNAL qualifier and the location of the parameter file is no longer "wired".

Another hint (maybe I shouldn't give away too many in one reply so I can start building up points!):

The value used for the /JOURNAL qualifier (and others like /OUTPUT) does not have to be a valid file spec if it "looks like" a part of a valid file spec or if you enclose it in quotes. So you can do:


$EDIT /TPU /SECTION=wherever:mysection.tpu -
/JOURNAL=RED ! or GREEN or BLUE, etc.

and in the tpu code in mysection.tpu you can do:

color := get_info(command_line,"journal_file");

and then probably test for a valid color, etc.

Or you can do the following:

$EDIT /TPU /SECTION=wherever:mysection.tpu -
/JOURNAL="6 RED SINGLE"

and then do:

params := get_info(command_line,"journal_file");

and then extract the three parameters using index and substr functions on the params variable.

Finally, you can use the qualifiers like /READ_ONLY to represent any boolean paramters you need to pass in to the custom tpu program.

Hope that helps - Mark

[Hoff]

What the OP very likely means by "welded" is "hardcoded", and I'm guessing the OP isn't familiar with OpenVMS, nor with logical names, nor with OpenVMS terminology in general. (I teach classes on this, and the mapping from bash terms and concepts to those of DCL is fodder; this and related confusion crops up regularly.)

Within the existing TPU application code, replace the "welded" specification that might look like this (for instance) "dka0:[directory.subdir]mumble.foobar" with the specification "happyhappy:mumble.foobar" and then (prior to activation of the TPU stuff)

DEFINE happyhappy dka0:[directory.subdir]

and off you go. Prior to activation of the TPU code, set the logical name happyhappy at what you want to target, and off you go.

With a little more detail on what you're up to here, I might well be able to provide one or more alternatives -- but this logical name approach is what you think of by "system symbols" in the OpenVMS context.

For folks familiar with Unix and not familiar with OpenVMS, logical names will be confusing. They're somewhat like bash shell environment variables and somewhat like softlinks, but then not really. And what is more analogous to environment variables -- DCL symbols -- are different from environment variables, and logical names are yet different from symbols.

To the OP: here's some useful reading on asking questions

http://www.catb.org/~esr/faqs/smart-questions.html

Understanding how to ask questions is key to getting faster answers (and better alternative solutions) to your questions.

Stephen Hoffman
HoffmanLabs LLC

[Wim Van den Wyngaert]

Another possibility that requires only a DCL to convert the output sh symb * in a TPU procedure.

$ ty wim.lis
procedure wim_set_sym

symb_a := "SET DEFAULT CFT_SEND:";
symb_b := "1";

endprocedure;


$ ty tpu.init
TPU wim_set_sym


$ EDIT/TPU /INIT=TPU.INIT/command=wim.lis

Then at the TPU command prompt do "tpu copy_text(symb_a)". You'll get SET DEFAULT CFT_SEND:.
So, all symbols are accessible as global variables in TPU.

Wim
(read the eve procedeures when they were simple in 1986 and wrote simple code to simulate the HP3000 editor FSEDIT and also some code to help cobol programmers)

[Wim Van den Wyngaert]

Here is a .com to execute for generating the TPU procedure. You must make sure that symbol names are valid as tpu variables. So, no * etc. May be do sh symb f* or whatever to select your variables.

$ wo := write o
$ def sys$output toto.lis
$ sh symb */glob
$ deass sys$output
$
$ open/write o wim.lis
$ wo "procedure wim_set_sym"
$ wo ""
$ open/read i toto.lis
$r:
$ read/end=e i x_rec
$ pos=f$loca("==",x_rec)
$ nam=f$extr(2,pos-3,x_rec)
$ if f$loc("*",nam) .lt. f$len(nam) then goto r
$ val=f$extr(pos + 4,999,x_rec) - """
$ wo "symb_" + nam + " := " + """''val'"";"
$ goto r
$e:
$ wo "endproceduure;"
$ close o
$ close i
$ del/noconf/nolog toto.lis.*

Wim