bottom
return
I often am asked for help, especially to do with RFTs. Sometimes by people who have attended my classes in the past, often from others. These problems are a major source of my own education!
And I don't always get the full answer first time. Thanks to those who read these pages and email me with their comments!
I have been asked about the title of this section. Notes & Queries is the title of a very popular column in the British newspaper The Guardian, here they publish readers questions, such as 'why is water wet?', and if a plane carries a crate of birds, and the birds fly in their crate, is the plane lighter while they are not on their perches'. Readers send in their answers and arguments betwen learned professors have ensued. You can read and contribute to them at The Guardians web site.
In this section I would like to share some of the more interesting ones. They are
Two people (Hans in Sweden and Frèdèric in Canada) have experienced unexpected results when performing Y2K testing. Their external date format is not common, being YY/MM/DD, which is the same as their internal date format. They could search for all records in a year by entering 98. in a search field. But when they changed their internal date format to YYYY/MM/DD while keeping the external format YY/MM/DD this search no longer was acceptable.
The date conversion routine was not adding the appropriate century infront of the year.
The short answer is that using the ignore dot (.) will only work in a date field when the internal and external date formats are the same. If they are not the same, you have to use the internal format in the field. This only involves adding a new validation pattern to the date search assisted entry panels to allow NNNN</>NN</>NN and informing users to search using a 4 digit year.
Frèdèric in Montrèal Canada wants to add fields to the block data (title) area of a table panel. He has read the BLOCK DATA LINE help panel BLM2FD04 which says "the information contained in the block data area may be modified if required", however the PMF manual says it cannot be used for fields. Frederic wants to know which is correct.
I am certain the answer is that you cannot use PMF to display data. The full text of the help message say the area can by used by the program that calls the table panel, eg the SEARCH commands inserts the DATABASE 5 comment. Frèdèric did not say what he was using the table panel for, and what information he wished to display. If it is a table panel used b y a record, such as FFT, validation list, or list processor panel, then it may be possible to display data from the record, such as description (validation records show the RNID/.). But it would involve tweaking the program invoking the table panel and that is outside my expertise.
Does anyone have anything to add to this?
"Here is the scenario....A user does a command line search and gets a search results list. He wants to print every record in the list. Using the block commands, he types PP on the first line of his SRL and PP on the last line. This will give him a detailed print of each record.
Problem...The RFT used is BLMPRPR. The report prints double-sided. We would like to see each record print on a new page. Currently if the first record is 3 pages long, the second record will begin printing on the back side of the second page. We would like a page-eject based on a new record number. As it stands now, if these two records need to be distributed to different groups (or filed in different binders, etc), the user must photocopy this page on separate sheets. Double-sided is OK as long as the record number doesn't change.
I don't know how to code this requirement in an RFT or even if it is possible. The command EJECT doesn't work."
I think the difficulty here is because multiple prints are being sent to a dataset which is ignoring blank pages. The PRINT command will deal with just on record at a time. If you put PP on the top and bottom of a search results list of 100 records, the print routine runs 100 times, producing 100 reports. If you send it to a dataset they are concatenated one after another (unless your profile is set to FREE PRINT, but thats another story).
Adding the following code after the last ESECTION will add a blank page after each record output.
/*-------------------------------------------------------------------*/
/* PURPOSE - ADD BLANK PAGE AT END OF EACH RECORD PROCESSED */
/* BY BLMPRPR (PROBLEM RFT CALLED BY PRINT COMMAND) */
/* USE - ADD THESE LINES TO THE FOOT OF BLMPRPR AFTER */
/* LAST ESECTION STETEMENT */
/* CODER - PETER MAY - peter@pmay.com */
/* http://www.pmay.com/infoman */
/* DATE - 1998/06/09 */
/*-------------------------------------------------------------------*/
SECTION
EJECT /* FORCES NEW PAGE
TITLE /* REMOVES TITLES SET BY PREVIOUS SECTION
ETITLE
HEADING /* REMOVES HEADINGS SET BY PREVIOUS SECTION
EHEADING
PUT COL(01) VAL(' ') /* OUTPUTS BLANK
ESECTION
This will ALWAYS put a blank page at the end of a print of one
record number. That could mean that if you have a 2 page print
followed by a 2 page print you would get
/*-------------------------------------------------------------------*/
/* PURPOSE - ADD BLANK PAGE AT END OF EACH RECORD PROCESSED */
/* BY BLMPRPR (PROBLEM RFT CALLED BY PRINT COMMAND) */
/* WHEN LAST PAGE IS ODD NUMBERED. THIS IS TO ENSURE */
/* FIRST PAGE OF ANY RECORD IS NOT PRINTED ON BACK */
/* OF ANOTHER RECORD WHEN PRINTING DUPLEX */
/* USE - ADD THESE LINES TO THE FOOT OF BLMPRPR AFTER */
/* LAST ESECTION STATEMENT */
/* CODER - PETER MAY - peter@pmay.com */
/* http://www.pmay.com/infoman */
/* DATE - 1998/06/09 */
/*-------------------------------------------------------------------*/
SECTION
/*-------------------------------------------------------------------*/
/* NEXT LINE DIVIDES LAST PAGE NUMBER BY 2 AND SETS VARIABLE TO
/* THE REMAINDER
/*-------------------------------------------------------------------*/
SET NAME(PAGE) VAL(&ZPAGENO) OP(//) VAL(2)
TITLE /* REMOVES TITLES SET BY PREVIOUS SECTION
ETITLE
HEADING /* REMOVES HEADINGS SET BY PREVIOUS SECTION
EHEADING
IF VAL(&PAGE) OP(>) VAL(0) /* TESTS IF LAST PAGE IS ODD NUMBER
EJECT /* FORCES NEW PAGE
PUT COL(01) VAL(' ') /* OUTPUTS BLANK
EIF
ESECTION
Miriam in the US asked "after we update a change record we can alter the description panel. Is there a way to protect the text on the description panel that was filled before we update the change record again? If so, with what information/management version we could do this? I couldn't find this information on manuals. Please, any idea will be very appreciated."
I replied that there are a number of things you can code to achieve what you want. But it is not standard in Info as shipped because the assumption is that if someone is authorised to update a record then they can change the details. And Free Form Text keeps an audit trail (date/time/userid) of anyone who changes existing FFT. (when using the Info editor - if using the PDF editor TEXTAUD can force usage of Info editor on update)
So, if you do not want anyone to update the FFT (are you sure? what about the change manager?) you can take the user to a display panel when the record is updated by using a control panel to test whether the user is creating or updating the record. This solution works with all Info/Man versions.
Larry in the US said "I'm using the old style list processor where you have multiple lines where data can be entered. When using the findsdata in a TSP how can I scroll through the fields to check for data. Normally I can use the Findsdata First and then Next but in a List Processor it's alittle different gathering the data. Any help would be appreciated."
My reply is that you can still use FINDSDATA first and next!
On the FINDSDATA LINE use the index of the root structured word, and
in field 3 use 5C5C (thats hex for **) Like this
1. Structured word index.... 1416 2. Get list index?....... NO_ 3. List index............ 5C5C 4. Prefix index............. 0000 5. Panel name............... ________ 6. Get variable data........ NO_ 7. Word occurrence..........Here you are saying find first instance of s-word 1416. Then you can do a FINDSDATA next to find the next entry in the list, like thisFIRST 8. Treat as string data..... NO_
1. Structured word index.... 1416 2. Get list index?....... NO_ 3. List index............ 5C5C 4. Prefix index............. 0000 5. Panel name............... ________ 6. Get variable data........ NO_ 7. Word occurrence..........Or you can start from LAST then work backwards by using PREV.NEXT_
Frèdèric from Montrèal read my article on dependent validation lists and wants to use them, but he does not want the dependent validation list to have a record ID (RNID/.) that matches the data in the independent field. So if the independent field could have either the value A or B then a dependent field would need two validation records, RNID/A and RNID/B.
Frèdèric says 'I would like to use another name instead so I could create a standard (example RNID/VRECP001, RNID/VRECC001, RNID/VRECC002....). This way I won't create a mess with validation records.'
The problem with dependent validation records is they use the data in the independent field as their RNID/.
If the independent field can only have two values (A or B) then you
could change its assisted entry panel target to point to a control panel.
The control panel tests for value A, if true goes to a new AEP that names
a validation record which holds the appropriate values, if it is value B
then goes to another AEP that names another validation record holding
the appropriate values.
Can anyone think of a better solution?
A company had two employees, Andrew Marshall and Andy Marshall. But when they searched for Andy they found also records for Andrew and vice versa. They asked me "Why"?
The answer is that, by default, the key in the index to the database
(the SDIDS) is sixteen bytes. The site standard for names was surname
followed by first name separated by a slash. If you add a five character
p-word, then the database (SDDS) entry for these names would read
PERS/MARSHALL/ANDREWBut the index (SDIDS) would read only the first 16 bytes.
PERS/MARSHALL/ANDY
PERS/MARSHALL/AN
PERS/MARSHALL/AN
The answer is to increase the SDIDS key definition to 32 bytes, which will cognize the entire field length with a small performance cost.
Poi Tong in Singapore had a nasty problem. His site was migrating from version 4.1 and all their panels were in one panel dataset. He could not identify which panels had been modified, and which were unmodified.
I wrote him a TSP which performed a bulk update of all the panels, did a View Internals on each, discovered if they had the modified field set to yes, and write the panel name to a list record and cancel the update. Then by running a report on the list panel we had a printed list of all modifed panels.
I have come across this problem again. It is most important for ease in changing versions that all locally modified panels are easily identified. The best way is to keep them all in one separate panel dataset.
Andy in England wanted the help desk and problem managers to be able to update problem records at any time. The difficulty was they were using record ownership. And if you are not in the owning class you cannot update a record that is currently owned by that class. There were too many classes to put the managers into each class, and anyway they didn't want to have to keep changing classes. Andy's idea was to put them into Master class, but this isn't good for security and anyway it still means they have to change class - and more important - remember to change back.
The answer is simple. The record access panel (BLG1A115 for problem records) checks record ownership. We created a new authority and addded it to the two managers classes. Then we modified the record access panel to test for this authority code and go directly to the update summary panel of the problem record thus bypassing the ownership test.
top]
Piet in South Africa wanted to obtain the total number of problems per department as well as printing out their details. This can be tackled in two ways. If the number of departments (GROS/.) is small, and the names are known, then 'bumping' up a counter by using IF/EIF is a simple way.
If there are a large number of departments and/or the names are not known then a technique we use in my course Customising Info/Man Reports (EA79) can be used. Sort the records by department. Set a variable to the department name and set a counter. Test each subsequent record's department field to check if the data is the same as the variable. When it is not equal it means you have finished with all the records for the current department, so you can then put out the counter total, reset the variable and carry on.
top]
Stefan in Stockholm noted that whenever a record was created using the web-connector feature that record did not show details of the individual who raised the record, only the default id of the web-connector task. Stefan wanted the normal audit information to be held in the record. A quick call to Dougie Lawson who is the Info web guru, ascertained that Info/Man 6.3 fixed this problem.
top]
Not every question can be answered to the callers satisfaction. Mike in Reading wanted to be able to change privilege class while remaining on the same panel. He added a new option onto the Profile summary panel (BLG0PU00) thinking that when you leave the Profile summary panel you are always returned to the same panel on which you issued the Profile command. The option had the same control information as the selection for changing Privilege Class on the primary option panel.
It is an ingenious thought, however Info/Man was not having it and gave error messages about wrong environment.
When you are in Profile you are in an environment created by the profile exit. It won't allow a call to the exit which initialises the privilege class environment (or vice versa).
I did try it out without success. But I did not agree with the request. Whereever you are in Info/Man is a result of your privilege class. Every selection and option you take from the primary option menu tests your privilege class to see you have the required authority. Users can take the same selection and be taken to different panels, depending on the class they are in.
It would be very undesirable to do what Mike wanted. In this case not only was Info doing what it was designed to do, but it was also working the way it should do !
Well, yet again I was wrong. It is possible, and I have done so. It involves adding a panel between the Profile selection and the call to change privilege class.
Thanks to Dan Price who gave me another reason why one would want to change class from a SRL which is when approving change records on behalf of several different classes.
top]
Cheryl from the US wants to have a pre-formatted freeform text area.
The normal way to do this is to create a record containing the form and file it in the database then use the record copy exit (BLG01439) to copy over the freeform text. Alternatively you could re-code the selection that creates a new record to copy an existing record.
If you are using the PDF editor then you could use an ISPF macro to copy in a pre-formatted page.
top]
Leon wanted to know who had deleted a record from the database. They had managed to recover it from an archive, but can you tell which individual deleted it?
Thanks to Dan Price of the US Federal Reserve Bank who tells me that if you use a control panel to add USER/ and DATM/ and TIMM/ when the user confirms deletion the details are added to the record before deletion and stored in the SDLDS, (Log Dataset). Thus the identity of the person who deleted the record can be retrieved from the SDLDS.
Otherwise the answer I originally gave was
There is no way in the standard Info/Man to tell who deletes a record. The power of deletion is controlled by privilege classes. The normal way would be that if the record deleted was a problem record, and only the problem manager has the authority to delete problem records, then it must be the problem manager that deleted it.
At Leons site they had given MASTER authority to a large number of people. So anyone of them could have deleted the record. I suggested taking MASTER authority from them, and giving only those who needed it the authority to delete records.
You could modify the 'confirm purge request' option to invoke a TSP. The TSP could update a list panel on an audit record that would hold the RNID/ of the deleted record plus information about who deleted it. I have done this, combining it with a panel that says details of the deletion is being recorded.
top
return