I have defined a 'Global' variable for 'postman' to be used under the postman's documentation.
However after loading the documentation it looks like the variable is not coming through at all. I can see what its assigned to but not the actual expected value is there.
If I set this variable under a particular environment then it works fine.
Is there anything preventing global variables to work in documentation? has anyone else faced this same issue?
p.s I know variables in lower levels take precedence so I have removed them from all environments and only have them set in Global. Any help is appreciated
based on answer from #dannydainton above who works for Postman:
The functionality isn't there to be able to use global variables for
the documentation. Using the Environment or Collection level ones
would be the other options.
Related
I read a JSON file for configuration information that the Django app needs. Rather than read it every time, I'd like to keep it in memory somewhere. Only, I don't know how to do this in Django. What's the best way to keep simple configuration information in RAM, so that it's accessible anywhere in the app?
You can keep the variables that you want to access as Environment variables and access them in your code.
export AWS_ACCESS_KEY = "<your_key>" # set environment variable
os.getenv('AWS_ACCESS_KEY') # access environment variable in your code
I'd suggest you to version control what ever config it is and use it to run the system the reason being it will be extremely difficult to replicate or debug these kind of issues.
But if you feel your scenario is exceptional your best go will be global variables.
You can use a global variable in other functions by declaring it as global in each function that assigns to it
I am using the boost unit test framework. I use the BOOST_TEST_MESSAGE function, and therefore I need to set the log level to at least message.
From reading the doc, I can do the following:
I can add somehwere boost::unit_test::unit_test_log.set_threshold_level( boost::unit_test::log_messages); However, the doc indicates it to be generally considered bad practice.
I can set the environment variable BOOST_TEST_LOG_LEVEL appropriately. This is a bad solution for me, as I will distribute my code, and I do not have a good way to constrain the user to set this environment variable appropriately in their bashrc.
Does anyone know a proper solution to this?
The best solution was simply to use the command line argument --log_level when running my binary.
z/OS 1.11, MXG 32.10, SAS 9.3, Batch
I'm working on upgrading MXG to 32.10 with SAS 9.3. While running a CICS report today, I received the message that MXG was taking 20x to 30x CPU processing to decompress messages because the decompression exit was not enabled. To do so, I have to set the macro variable &SMFEXIT to CICS in each run, as follows (I had already assembled and linked the exit and had it available in STEPLIB):
%LET SMFEXIT=CICS
Other options are available but they are more complex and still need set every time I want to access the CICS data. I used it in my program and it worked fine and ran much, much faster.
I figured I'd put this into AUTOEXEC. It didn't work there. AUTOEXEC seemed to process normally with no errors, meaning there was no output at all... It may have had a warning, but that wouldn't show. Only errors display from AUTOEXEC.
I found that I could specify global option ECHOAUTO, along with SOURCE, to display AUTOEXEC processing. That has to be done either in CONFIG or as an invocation parameter. I tried both options and neither worked. I purposefully misspelled it in CONFIG and that threw an error, so I know it was being found. SAS lists the invocation parameters in SASLOG, so ECHOAUTO and SOURCE were both listed there. I received no indication that those options were working and AUTOEXEC processing just didn't go to SASLOG.
I ran PROC OPTIONS RESTRICT and nothing was restricted.
All the messages kept telling me to talk to the System Administrator. I found nothing that told me who that was, what they were supposed to do or how to find out... I sit by our System Administrator and he was no help with this because I'm the one that knows SAS. Or, I thought I did...
So, how do I set &SMFEXIT to CICS globally? Bonus for information as to why ECHOAUTO totally ignored me and information about the System Administrator. Also, where can I find information about the limitations of AUTOEXEC as in what can or cannot be there. Better yet, tell me in what guide I can find this information myself. I searched for a long time and couldn't find any of that. SAS documents are many. SAS information about these questions is either scarce or just impossible to find.
Thanks...
UPDATE: I am considering setting up my MXG proc so that it has a concatenation that throws in this control card ahead of the MXG/SAS programs. Seems like an awful hack... Still would like other options and answers to the ancillary issues IAAP. Thanks again.
Ah yes, the head slap... Every issue above is easily explained by the fact that AUTOEXEC is not being called! Variables aren't set. Logic isn't added to the SASLOG.
We use Windows SAS, too. We use AUTOEXEC.SAS to extensively initialize that environment. On the other hand, on z/OS, we use JCL and parameters to initialize SAS without using AUTOEXEC, so it has never been implemented.
On z/OS, the AUTOEXEC global option defaults to the SASEXEC ddname. I added the appropriate JCL to my MXG PROC to point to my AUTOEXEC member. Voila. My variable is set. The logic is available in SASLOG. Everything appears to be working, all with one simple root cause.
Thanks...
I use the GDAL. CPLSetConfigOption("GDAL_DATA", "mygdaldir") works, but throws an exception when finishing the app. It is possible to set GDAL_DATA as "global" environment variable but I want to do it programmatically for the current process instead of configure it externally.
Any ways how to set an environment variable for the current process/app itself?
EDIT:
Found the problem: GDAL_DATA pointed to the wrong directory => GDAL fails to unload correctly. Anyway, #Greenflow gives us a fitting answer to my question and even if I don't need his solution I accepted his answer.
You might want to read the docs for qgetenv and qputenv.
I just started to use doxygen and may not be familiar with all available settings. I looked into all tags and options in configuration file, but havent been able to locate any relevant tag for the operation.
Is there any way to force doxygen to index externals in C/C++ ? Now they just plainly added to list of other variables in the source file.
EDIT: From what I have seen so far, is that doxygen doesnt understand the externals at all. It generates a references in html files for these variables or functions to random ( first seen ) locations
Local variables with file-only scope are marked as static, right? So when setting EXTRACT_STATIC to NO you won't see them at all.
That said: there is now no clear distinction between static and external variables in the index. I have plans to redesign the indexes to make them more interactive and then I will take your wish along (i.e. be able to filter on static v.s. external). If you want to be notified on when this happens please file a bug report with severity set to enhancement in doxygen's bug tracker.