On Fri, 29 Mar 2019, at 16:02, Paul Gilmartin wrote: > Neat! I never became proficient with the ISPF variable pool. > > Is there any restriction on the content of ISPF variables? Special > characters? Length? > Can they be delimited strings, subject to the design deficiencies of > delimited strings?
I'm sorry, it's been 20 years since I did any of this, and even if I could remember the limitations then, they might have changed. I should have added earlier that I usually used the same vput/vget method to pass flags and/or extracted data back from the macro to a calling exec. My macros would typically issue "builtin save" if a file had to be modified by the macro, then continue to test the rc from the save, do the necessary vput(s), and finally "builtin cancel" to end the edit session. In the calling exec the rc from the (ispf) edit would be checked, because invoking edit might have failed, eg because of spfdsn enqueues on the target file. In the 'production' systems I wrote the execs usually then slept for a few seconds, then tried again (when they were part of the batch jobs). If the edit was something invoked from an ispf dialog run in the foreground, the dialog might have told the user to try again (as they'd probably already have seen a line-mode dataset contention message). Then (if invoking edit had worked) the exec would vget the vars setup by the macro and analyse those to find out if the macro had worked. (Sometimes, those vars that should have been created by this run of a macro, would have been preloaded with "it didn't work" values, in the exec before I called edit.) I don't (at home, 20 years on...) have any examples of the typical 'production code' versions of any of these, unfortunately. -- Jeremy Nicoll - my opinions are my own. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
