I was asked about posting non-Ellucian reports to ePrint. Wouldn't this be a nightmare, since headings and page breaks wouldn't be the same? I fear that we may open up a can of worms and get stuck rewriting everybody's reports so they look good in ePrint. Any advice?
Many factors must be considered. What type of reports do you mean? What report writer is generating the reports? The process you would follow is the same as with the standard Plus reports. There is a little work but it's not a large task. The biggest consideration is what is used as the carriage control for the top-of-page. After that it is just where are fields located on the report. Since all the Plus reports have the same format, this makes adding new reports easy -- just select a template, copy, and make a few changes.
When setting up ad-hoc reports, develop a standard format that all reports would use regardless of the tool used to create the report. This is fine if you are starting out, but if you have reports already created, do you want to change all of them to this new format or just bring them in as is? Bottom line is that it would be a little more work if the formats are different, but it's more like 2-5 minutes, not 20-50 minutes.
As of the 3.3-1 release of ePrint, the archiving process now allows the creation and download of ISO images suitable for download and burning of CDs and DVDs.
There is no way for archive sets to span multiple CDs. However, the 3.3-1 release of ePrint supports burning DVDs, which have approximately 5 times the capacity of a CD.
These are important directories that you want to back up in order to facilitate a data recovery if necessary: /etc and /home. Anything taking up space in /home is important, so it is best to grab the whole thing. The /home directory holds all the ePrint data and the mysql data.
There is no way for you to selectively restore from the backup tape. Basically, the backup created is for disaster recovery situations and for full system restores in the event of something such as a hardware failure.
Have him clear the cache in his browser and try again. This normally will resolve the problem.
The reason you keep getting that message is because by default, Internet Explorer (IE) is set to create this warning message as a security precaution. To eliminate this message, in IE go to Tools -> Internet Options. Under the Advanced tab, deselect, "Do not save encrypted pages to disk." You shouldn't receive the IE warning message anymore.
This error can be caused by a couple of things -- either the browser is not clearing the cache, or they are using the browser BACK button when they should be using the ePrint navigation bar. The only time that the browser BACK button should be used is to get back from reading a pdf report from within the browser. Have them clear the cache.
You can open ePrint in another browser window and compare the reports. This means that you would be logged in twice.
If a user is using Internet Explorer (IE), it is better to open Adobe outside of the browser. Also, if the user is using https to access the reports, the problem may be because of a security precaution in IE relating to encrypted pages. To eliminate this message, try this: In IE go to Tools -> Internet Options. Under the Advanced tab, de-select "Do not save encrypted pages to disk". Once this option is no longer selected, the warning message should go away.
According to the Safari web site, the latest version handles 128-bit encryption fine. Almost all browsers today support 128-bit encryption. The reason that Mac/IE has problems may be due to the fact that they stopped development on it and didn't fix the problem before they did so. Safari is the default browser for Mac's so I imagine they did a better job with the SSL 3 support then what Microsoft did with their Mac version of IE.
If you are using Internet Explorer as your browser, right mouse click, save target as, and save the file to your desktop (or wherever you want). Then go to the file and open it, this should open Excel and display the report in CSV format. If you use the primary mouse button to click the "Data" icon, this will cause Excel to open within the browser and not perform the CSV processing.
As far as being prompted to save the file rather then just opening it, this is neither an ePrint nor an Excel issue. Rather, this is dependent on which Web browser is being used and how the browser is configured. When dealing with the CSV files, they should always save them to their hard drive first (right click and "save target as"), otherwise they will display incorrectly, just as you have described.
Yes, you can FTP the files from your PC to the ePrint server. We would need the IP address of your PC and put that on the server as an address that can FTP to the server. When sending over pdf files, be sure to transfer them using "binary" mode which should be an option with your FTP client. Otherwise, the file may become corrupted and display incorrectly.
It sounds like they losing their login session. Make sure their browsers are set to accept cookies. Also make sure their "Privacy Settings" are not too high. Anything higher than "Medium" may cause problems such as the one you are describing.
If you are using Internet Explorer (IE) as your default browser, be sure to configure Adobe Reader to open outside of the browser. There are known problems with the Adobe/IE plug-in that occasionally causes a dynamically built pdf to not open correctly.
This may be the result of a browser upgrade that changed the pdf file association in Windows from Adobe Reader to an Internet Explorer (IE) mime-plugin for Acrobat. I ran into this after an IE update and took the following steps to fix it: Click My Computer, then Tools > Folder Options. In the box that opens up click the tab FILE TYPES. Scroll down to pdf (or Adobe Acrobat Document) and click Change. In the new dialog box, Select Adobe Acrobat and click OK. This will give the correct path to launch Acrobat Reader when clicking on a pdf file.
This message could be caused by a couple of things. First, cache is not being cleared in the browser. Clear cache and see is the message still displays. Second, the user is using the browser BACK button instead of the navigation bar within ePrint. If this is the case, use the navigation bar and the message should stop appearing.
Does ePrint support Mac users? If so, which Mac OS and which browsers?
Mac users shouldn't have any problems accessing ePrint. However there are known problems with Mac's Internet Explorer (IE) SSL implementation and since Microsoft stopped development on it, the issues will probably not get fixed. With that said, I highly recommend that Mac users DO NOT use IE. Also, I have heard there are users running Safari, Mac's default browser, and no problems have been reported with it.
This is what you can do:
Create an archive as you normally would.
Log into the ePrint server with the eprintop login.
Select the archive set that you want.
Continue as you normally would.
The reports will be generated, but the process will error because there is no burner. There will be a file in /scratch/image/ called "test1.raw"
This will be the image you will want to burn. Transfer the file to another machine, then burn the image to CD.
Prior to the physical burning of the CD, you will be informed as to how much of the CD will be used. If you exceed 100%, you will need to remove data before burning. The process will not continue if you exceed 100% of a CD.
The time frames vary for each site and are based on the number of people involved, their skill sets, and the time available for the configuration task. Last week we had a customer finish the entire configuration steps in four days. This was one person working part-time each day, about an hour or so, on the configuration. She had access to the Oracle database as a DBA, so she was able to create the ePrint server user and configure the ePrint classes herself. She was familiar with Unix so she was comfortable loading the automated FTP scripts. Most of all, she was familiar with ePrint so she was comfortable creating a Banner repository. She also spent time up-front reading the documentation and understanding the steps involved. The average time frame is a few weeks of part-time work for one or two resources. You will need a minimum of two skill sets for the conversion, a Banner DBA and an ePrint administrator. Later on for testing you will want to involve someone with functional ties to the repository, either Finance or HR. We have had sites take from 4 - 5 weeks for a variety of reasons including inadequate skill sets and resources with no time to invest in the configuration. So, if you are the DBA, I would estimate two weeks, just to be safe. You will be doing the work part-time and you will have many demands pop up that take you away from the project.
When you create your new fiscal year repository using the report definition wizard, on the first page, you will find a "radio" button next to "Copy multiple report definitions as templates." Select the original repository from the drop-down list and then highlight the report definitions that you want to copy. You may use the Shift key to select a range or the CTRL key to select different individual definitions. Click the CREATE button and this will copy all of the selected report definitions to your new repository. Make individual adjustments to each report definition and you are all set.
No, the process of moving reports from one repository to another is not supported by ePrint. This is not a simple task, due in part to the databases behind ePrint and the many dependences that would need to be in place before the reports could be moved.
Here is one method that you can use. First copy the report definition from the original repository to the "new" one. In the "new" repository's report definition, change the "Top of Form" to Fixed_length and save these changes. Now go back to your original repository. Go to Stored Reports and download the "TEXT" version of the report you want to move. FTP the downloaded file to the "new" repository -- don't forget the .done file! The report will parse and it will now be in the "new" repository. Repeat the download of the TEXT and FTP steps for each instance of the report that you want to bring over. The only issue may be that the IP address of the desktop that you will be doing this from is not defined to the server as a valid IP address for FTP. Just let us know and we can make that change for you.
In the report definition for fgrodta, the file name is "fgrodta," so that is what ePrint is looking for. Rename fgrodta.lis to fgrodta and you should be all set.
The DATA icon will only appear if you define CSV parsing for that report. When you use a report definition from one repository as a template for that same report in another repository, ePrint will just copy the report definition. If you want the DATA icon you can copy the CSV definition from the MVS repository as a template for the new FINDEVL CSV definition. The CSV definition is totally separate from the report definition.
The 65,536 line is the limit Excel can accept. The only workaround would be to split the report. With VBS the number of people who can see the entire report should be limited. The main question would be, is someone who has access to all the information likely to download to Excel?
The CSV function of ePrint assumes that it is working with a text report. From the text report ePrint will create the comma-delimited file as output. Because of this ePrint will always display the pdf and TEXT icons. A simple solution is to send the file as straight data and have ePrint create the comma-delimited file. In this case, the users can see the raw data to see what was input.
To get the DATA view option for a report, define a CSV definition. A report has to be defined first before you can do the CSV definition. Most likely a report that has columns of data are candidates for CSV. Define the columns of data that will be extracted to a comma-delimited dataset. You can review the help for defining CSV for a report. Once you have the CSV definition, the DATA icon will appear for all instances of the report.
If you are using Internet Explorer as your browser, right mouse click, save target as, and save the file to your desktop (or wherever you want). Then go to the file and open it, this should open Excel and display the report in CSV format. If you use the primary mouse button to click the "Data" icon, this will cause Excel to open within the browser and not perform the CSV processing.
As far as being prompted to save the file rather then just opening it, this is neither an ePrint nor an Excel issue. Rather, this is dependent on which Web browser is being used and how the browser is configured. When dealing with the CSV files, they should always save them to their hard drive first (right click and "save target as"), otherwise they will display incorrectly, just as you have described.
In looking at the reports, they are filed under 09/04/2003 but the report date is 02/09/04. When I compared these reports against the last "good one" (1/29/04), I noticed that the report is different. The "good" reports have on the heading line, DATE RUN: nn/nn/nn; the reports in question had, DATE:nn/nn/nn.
The date is in a different place, that's why they are not listed under the correct date. Change the date setting on the report definition in ePrint or on the heading of the report.
The location of the date changed from 119 (which is where your report definition is set) to 121. As a result, it was picking up the year as 20 (2004). So somewhere the report was changed. Adjust the report or the definition.
Yes, you can adjust the time. Here is an example to set it to 2:57 PM: date -s 14:57:00. If you have a time server on campus that we can use, we can synchronize the time on the server in case if drifts.
Do not delete this repository! The ePrint demo repository is used as the template for all new repositories. This is why you don't want to delete it. You can hide it so users will not see it on the drop-down list. To hide it, go to the repository config, select the ePrint demo repository and click the EDIT button. At the bottom of the Repository Config page is the Hidden setting; set this to YES.
It sounds like they losing their login session. Make sure their browsers are set to accept cookies. Also make sure their "Privacy Settings" are not too high. Anything higher than "Medium" may cause problems such as the one you are describing.
The e-mail will go to all users who have access to the report (and have their e-mail addresses in ePrint). Even if there are no pages for them to view, they would get an e-mail. ePrint does not check every user's report access to see if there is anything for them to see, it just knows that the report is ready.
If you set the "ID Type" to "E-MAIL" in the report definition, and put several e-mail addresses in the list, one e-mail will be sent from the ePrint server. If you have multiple "Notification IDs" set up, and each has a list of users, one e-mail will be sent from the ePrint server for each "Notification ID" that is set up.
In the report definition, you must set up the "Notification" section. If you specify an "E-MAIL" address, when that report is parsed the e-mail notification will be sent.
One Plus school added the user's e-mail address to the ZCFILE. They used a couple of fields that they did not use in ZSS and made it e-mail address. They added this field to the extract file and to the security definition in ePrint so they could continue to use Batch mode update. With Batch mode update you can maintain your users with ZSS and ePrint reflects those changes. After further discussion, we concluded that an update mode of "Both" would work for you. This will keep the e-mail addresses in ePrint. The drawback here is that when you delete a user from ZSS, you must also delete the user from ePrint. Another solution would be to include all the users e-mail addresses, separated by commas on the "Notification" page of the report definition. The drawback here is that you would need to add/delete e-mail addresses as the list of users changes. Each of these solutions requires some change on your part. Select the one that best works for you.
There is no limit on e-mail notifications; they should go out fine.
Change the number of lines to display to something like 999. You will see all the entries in the log. The display on the log files is the last x number of lines, where x is the number from the page (default is 100).
You sent the report and the .done file before you created the report definition file. This caused the parser to go into a loop. We stopped the parser and you will have to re-send the report and .done files.
The reason you keep getting that message is because by default, Internet Explorer (IE) is set to create this warning message as a security precaution. To eliminate this message, in IE go to Tools -> Internet Options. Under the Advanced tab, deselect, "Do not save encrypted pages to disk." You shouldn't receive the IE warning message anymore.
This error can be caused by a couple of things -- either the browser is not clearing the cache, or they are using the browser BACK button when they should be using the ePrint navigation bar. The only time that the browser BACK button should be used is to get back from reading a pdf report from within the browser. Have them clear the cache.
If a user is using Internet Explorer (IE), it is better to open Adobe outside of the browser. Also, if the user is using https to access the reports, the problem may be because of a security precaution in IE relating to encrypted pages. To eliminate this message, try this: In IE go to Tools -> Internet Options. Under the Advanced tab, deselect "Do not save encrypted pages to disk". Once this option is no longer selected, the warning message should go away.
Unless the report is being generated differently, or is coming from a different source, there should be no need to change this setting in the report definition. So you will want to set it to your original "Top Of Form" value.
ePrint looks for the VERIFY STRING on the first page of the report (after getting rid of the junk pages). Since you are getting rid of two pages, we look on the third page for the verify string and the value "PAGE" is not on the page, so the verification fails. What you should be able to do is set junk pages to 1, and then "PAGE" should be found since it is on the what is now the first page (actually Page 2, but ePrint gets rid of 1). It looks as though you may have to adjust the location in the report definition, since "PAGE 2" doesn't appear to be in the same column as "PAGE 1."
You are receiving that message because there is a blank line before the first page delimiter (page break) on the report. When ePrint finds the blank line, it considers it a page. Then it finds the control character and treats that as a page break, and it handles the proceeding lines as page 2 data. To get the report to parse correctly, either define a junk page to get rid of the first page (page that contains just the blank line) or eliminate that blank line when the report is generated.
Even though a user has access to a report, there may be no data on the report for them to look at. This may occur when a report is controlled by value-based security. One month they have pages to view but next month there is no activity, so there are no pages for them to view.
There are duplicate page keys defined for this report. There are two DEPT at level 0.
That information is not logged. It is a warning only. When reports are created they will be created based on a certain number of lines per page. The number of lines per page is recorded in the report definition file. If you received this warning, I recommend that you increase the value for the number of lines per page in the report definition.
This message is not an error. This message was displayed because it took over one minute to parse a report (bbd120). When ePrint parses a report the repository is placed in a "locked" state. The parser will "wake" after one minute to see if there is something to do. Since the report was still parsing, ePrint displayed the message. This will continue until the parsing is complete. This condition only exists when a large report is sent. The report parsed successfully.
The DATA icon will only appear if you define CSV parsing for that report. When you use a report definition from one repository as a template for that same report in another repository, ePrint will just copy the report definition. If you want the DATA icon you can copy the CSV definition from the MVS repository as a template for the new FINDEVL CSV definition. The CSV definition is totally separate from the report definition.
In your report definition for FGRCTRL, you have two page keys defined and both are level 0. The page keys are for acct and account (both of these are used in FRS but not Banner). You may have these left from either the default or you copied the definition from an FRS report and didn't change it. Make sure you have the correct page defined because you are trying to use VBS and it won't work without the correct page key defined.
In the future, remember not to FTP a report file (or at least not the .done) until after the report definition has been completed.
The message that you received on the FTP step, zwoffl: Permission denied on server (Overwrite), means that the ZWOFFL file already exists in the security incoming directory of this repository. To move the new ZWOFFL file into the correct repository/directory, delete the existing ZWOFFL file in ePrint. To do this:
1. Log in as the Administrator
2. Go to Security Incoming, located under the File Maintenance heading
3. On the Security Incoming Directory page, highlight the file (ZWOFFL)
4. Click the delete button. You will be asked to confirm the delete. Click OK
When loading security, you need to send at least four files: ZWOFFL (the output from ZBPS10), the authentication.done, FWOAFL (output from FBPS10, if FRS VBS is used) and vbs.done. Make sure you have all four and try it again.
If you are using Internet Explorer (IE) as your default browser, be sure to configure Adobe Reader to open outside of the browser. There are known problems with the Adobe/IE plug-in that occasionally causes a dynamically built pdf to not open correctly
When you FTP'd the pdf file you should use Binary, not ACSII.
This message could be caused by a couple of things. First, cache is not being cleared in the browser. Clear cache and see is the message still displays. Second, the user is using the browser BACK button instead of the navigation bar within ePrint. If this is the case, use the navigation bar and the message should stop appearing.
The parser got hung up on the report. This happened because the report definition was created while the report was already in the incoming directory with its corresponding .done file. In the future, you will want to set up the report definition before sending the files, or you will want to hold off on sending the .done file until you have the report definition created.
In your report definition for FGRCTRL, you have two page keys defined and both are level 0. The page keys are for acct and account (both of these are used in FRS but not Banner). You may have these left from either the default or you copied the definition from an FRS report and didn't change it. Make sure you have the correct page defined because you are trying to use VBS and it won't work without the correct page key defined.
The limit on the Report Definition Name is 30 characters. The limit for the Label and Description are both 60 characters.
How do I get a pdf file into ePrint?
Defining a pdf to be loaded into ePrint is similar to defining any other report in ePrint. Log in as an administrator; go to "Report Definitions" under "Report Tasks." "Create" a new definition. Once you are in the report definition wizard, enter a "Label" (optional), a "Description," and a "Filename" (optional). Next, toggle the "Input File Format" to "pdf." Then you will just need to FTP the report to the ePrint server with it's corresponding.done file. When FTPing a pdf to the ePrint server, be sure to use binary mode, otherwise the pdf may become corrupted during the file transfer.
Banner objects do have a character limit. If you are using the auto FTP you will need to follow the naming conventions in Banner. If it is a legacy report, in Banner you can assign an object name to the report, in ePrint create a report definition with the same object name, and in the report definition add the report file name. The report .done file that is FTP to ePrint will need to match the report configuration name or the Banner object name.
Are file names case sensitive?
Yes, file names are case sensitive. By default, if you do not specify a file name in your report definition, then ePrint assumes that the file name that will be sent over for the corresponding report definition will be lowercase. Otherwise, whatever you specify in the report definition for the "Filename" (upper or lowercase), is what you should name the file that you send to the ePrint server.
Yes, all reports go into the incoming directory of the repository. If no report definition uses that file name, then the file will remain in the incoming directory until you take some action -- either delete the file or rename it. A file in the incoming directory with no definition will cause ePrint to lock the repository. If you try to define the report any further processing will be halted. The recommendation would be to rename the file in the incoming directory, define the report, and then rename the file to its original name.
The report did not parse for two reasons -- the file name, and the missing .done file. The report name should match the report definition, which is fgrbdsc. Also, the parser will not start until there is a fgrbdsc.done file in the incoming directory. The auto FTP process will automatically rename the fgrbdsc_6302.lis to fgrbdsc and also create and FTP the fgrbdsc.done file.
In the report definition for fgrodta, the file name is "fgrodta," so that is what ePrint is looking for. Rename fgrodta.lis to fgrodta and you should be all set.
When an end-user logs on to ePrint they are presented the "Repository List," the list of reports that the user can view. For each report, this information is displayed:
REPORT - The value of the LABEL from the report definition.
DESCRIPTION - The description from the report definition.
When they drill down on a specific report, then the title of the report is displayed. This comes from the location defined in the report definition. As an administrator, you can change the LABEL value at any time. This field can include spaces and is 60 characters long. The report description field is 60 characters long.
Are you receiving this error when you try to open the report? The page keys defined in the report definition must match the VBS values that you use in the security VBS setup. In other words, in the report definition you will either have to use "sisuser" for the page key value, or use "user" in the security VBS setup.
As for the reports sitting in the Security Incoming Directory, the security loader also needs an "authentication.done" file. Once it is there, the security files should process.
How do I get a pdf file into ePrint?
Defining a pdf to be loaded into ePrint is similar to defining any other report in ePrint. Log in as an administrator; go to "Report Definitions" under "Report Tasks." "Create" a new definition. Once you are in the report definition wizard, enter a "Label" (optional), a "Description," and a "Filename" (optional). Next, toggle the "Input File Format" to "pdf." Then you will just need to FTP the report to the ePrint server with it's corresponding.done file. When FTPing a pdf to the ePrint server, be sure to use binary mode, otherwise the pdf may become corrupted during the file transfer.
Banner objects do have a character limit. If you are using the auto FTP you will need to follow the naming conventions in Banner. If it is a legacy report, in Banner you can assign an object name to the report, in ePrint create a report definition with the same object name, and in the report definition add the report file name. The report .done file that is FTP to ePrint will need to match the report configuration name or the Banner object name.
To get around this you need to assign a report to a group BEFORE parsing the report. Once you have created a report definition you can easily assign the report to a group, then FTP the report. If the report is assigned to something, it will not go to the default (USERS) group.
This is what you can do:
Create an archive as you normally would.
Log into the ePrint server with the eprintop login.
Select the archive set that you want.
Continue as you normally would.
The reports will be generated, but the process will error because there is no burner. There will be a file in /scratch/image/ called "test1.raw"
This will be the image you will want to burn. Transfer the file to another machine, then burn the image to CD.
The report did not parse for two reasons -- the file name, and the missing .done file. The report name should match the report definition, which is fgrbdsc. Also, the parser will not start until there is a fgrbdsc.done file in the incoming directory. The auto FTP process will automatically rename the fgrbdsc_6302.lis to fgrbdsc and also create and FTP the fgrbdsc.done file.
The DATA icon will only appear if you define CSV parsing for that report. When you use a report definition from one repository as a template for that same report in another repository, ePrint will just copy the report definition. If you want the DATA icon you can copy the CSV definition from the MVS repository as a template for the new FINDEVL CSV definition. The CSV definition is totally separate from the report definition.
The .done file name should be das.pdf.done. I changed it in your report incoming directory and the report parsed fine. The .done file should be the report file name.done; for example, report.file > report.file.done.
Are all the forms producing the same report name? If so, that is the problem. You produce the report and send it to the print queue. While the second one is being produced, the first one is being FTP'd to ePrint. The FTP function will not send another report by the same name until the current one (report #1) has parsed completely. This would explain why the first and last are in ePrint. Is there anything in the ePrint print queue on the Banner server? If you are running the same report, you need to delay the FTP so each instance can be parsed individually in ePrint.
The ePrint server allows an FTP only from the hosts we have defined on the server. If you give us your IP address, we can make sure that the ePrint server will accept FTP traffic from it. Then you will be able to FTP directly from your desktop to the ePrint server. FYI: When transferring pdfs to the ePrint server, make sure that you use binary file transfers, not ASCII.
Is it possible to have multiple FTP users for one repository?
No, there is only one FTP User/Password per repository, but you may use the user/password from multiple locations to ePrint. I'm assuming you want to send reports from more than one location? If so, they can all use the same FTP User ID. This should work fine as long as they are not all sending the same report at the same time.
The reason that you can't FTP to the server is because the server will only allow certain IP addresses to FTP to it. If you send us the IP address of the machine where you FTP from, we can add that to the server.
In the future, remember not to FTP a report file (or at least not the .done) until after the report definition has been completed.
If you you establish the FTP connection from a PC, you will use the FTP ID/password (from the repository initialization) and send the pdf file and the .done file. When sending a pdf file, send it in binary mode not ACSII. The ePrint server will need the IP address of the PC defined so the FTP transfer can take place. The process of sending a pdf file is the same as sending any other report to ePrint.
Yes, you can FTP the files from your PC to the ePrint server. We would need the IP address of your PC and put that on the server as an address that can FTP to the server. When sending over pdf files, be sure to transfer them using "binary" mode which should be an option with your FTP client. Otherwise, the file may become corrupted and display incorrectly.
The user will need to be set up as an Internet Native Banner user if you are going to be using Self-Service. Refer to chapter 6 of the Banner ePrint Integration Guide for more information.
Yes, all reports go into the incoming directory of the repository. If no report definition uses that file name, then the file will remain in the incoming directory until you take some action -- either delete the file or rename it. A file in the incoming directory with no definition will cause ePrint to lock the repository. If you try to define the report any further processing will be halted. The recommendation would be to rename the file in the incoming directory, define the report, and then rename the file to its original name.
This message is not an error. This message was displayed because it took over one minute to parse a report (bbd120). When ePrint parses a report the repository is placed in a "locked" state. The parser will "wake" after one minute to see if there is something to do. Since the report was still parsing, ePrint displayed the message. This will continue until the parsing is complete. This condition only exists when a large report is sent. The report parsed successfully.
The parser got hung up on the report. This happened because the report definition was created while the report was already in the incoming directory with its corresponding .done file. In the future, you will want to set up the report definition before sending the files, or you will want to hold off on sending the .done file until you have the report definition created.
In the report definition for fgrodta, the file name is "fgrodta," so that is what ePrint is looking for. Rename fgrodta.lis to fgrodta and you should be all set
The .done file name should be das.pdf.done. I changed it in your report incoming directory and the report parsed fine. The .done file should be the report file name.done; for example, report.file > report.file.done.
The parser got hung up on the report. This happened because the report definition was created while the report was already in the incoming directory with its corresponding .done file. In the future, you will want to set up the report definition before sending the files, or you will want to hold off on sending the .done file until you have the report definition created.
Unless the report is being generated differently, or is coming from a different source, there should be no need to change this setting in the report definition. So you will want to set it to your original "Top Of Form" value.
ePrint looks for the VERIFY STRING on the first page of the report (after getting rid of the junk pages). Since you are getting rid of two pages, we look on the third page for the verify string and the value "PAGE" is not on the page, so the verification fails. What you should be able to do is set junk pages to 1, and then "PAGE" should be found since it is on the what is now the first page (actually Page 2, but ePrint gets rid of 1). It looks as though you may have to adjust the location in the report definition, since "PAGE 2" doesn't appear to be in the same column as "PAGE 1."
You are receiving that message because there is a blank line before the first page delimiter (page break) on the report. When ePrint finds the blank line, it considers it a page. Then it finds the control character and treats that as a page break, and it handles the proceeding lines as page 2 data. To get the report to parse correctly, either define a junk page to get rid of the first page (page that contains just the blank line) or eliminate that blank line when the report is generated.
The report contains only one page of data and you have it defined with the last page as a junk page. ePrint is removing the last page, which in this case happens to also be the first page, and this leaves you with no pages. Remove the junk page and you should be all set.
Define the report with a junk page of type = LINES and Line = 1. ePrint will ignore the first line of the report. A number of the FAM reports place a page break before the first page, which causes problems in ePrint. This is not a "known issue," but just the way FAM reports are formatted. If the reports are printed, there is no problem. This is something that you will need to be aware of when defining FAM reports to ePrint. The FAM ActionLine looked into a change, but the effort was too great and would affect all of FAM.
If a user tries to login and is not successful after five attempts, that ID will be locked. To unlock the ID, go to the "Users" page on the Administrator Interface, type in the ID (or use the clipboard to find the ID). Click the "edit" button and click the "unlock" button. The user will now be able to log in.
Have him clear the cache in his browser and try again. This normally will resolve the problem.
There is only one Super Administrator ID in ePrint. More than one person can use that ID/Password.
You can open ePrint in another browser window and compare the reports. This means that you would be logged in twice.
How do we add our school logo to our ePrint server?
We can add the logo -- all you need to do is send us a .gif file with the logo that you want to use.
Change the number of lines to display to something like 999. You will see all the entries in the log. The display on the log files is the last x number of lines, where x is the number from the page (default is 100).
In looking at the reports, they are filed under 09/04/2003 but the report date is 02/09/04. When I compared these reports against the last "good one" (1/29/04), I noticed that the report is different. The "good" reports have on the heading line, DATE RUN: nn/nn/nn; the reports in question had, DATE:nn/nn/nn.
The date is in a different place, that's why they are not listed under the correct date. Change the date setting on the report definition in ePrint or on the heading of the report.
Are all the forms producing the same report name? If so, that is the problem. You produce the report and send it to the print queue. While the second one is being produced, the first one is being FTP'd to ePrint. The FTP function will not send another report by the same name until the current one (report #1) has parsed completely. This would explain why the first and last are in ePrint. Is there anything in the ePrint print queue on the Banner server? If you are running the same report, you need to delay the FTP so each instance can be parsed individually in ePrint.
Define the report with a junk page of type = LINES and Line = 1. ePrint will ignore the first line of the report. A number of the FAM reports place a page break before the first page, which causes problems in ePrint. This is not a "known issue," but just the way FAM reports are formatted. If the reports are printed, there is no problem. This is something that you will need to be aware of when defining FAM reports to ePrint. The FAM ActionLine looked into a change, but the effort was too great and would affect all of FAM.
Yes, when using Type = SCAN, it will start at the top of the page (Line 1, Position 1) and proceed as you have described. Once it finds that value, it will use that for the page key, and will not look for that value again until it gets to a new page. Only one occurrence of the page key is indexed per page.
To find this patch (66653 version 5.4.0.1), in Action Web, go to Extended Search and query on Known Issues. Select Banner Finance, status Posted, and process FGRBDSC. You will see this defect listed.
Also, you may go to Downloads, select Banner Finance and List Releases. Select your release (5.4) and List Files. The first file listed is always contents.txt. This is a combination of all the text for all the posted defects for that release. If you open contents.txt and search for your process name, you will find all patches that reference this process. Or you can search for patch 6653 and download the patch directly.
How often does the parser run?
A script is run every minute to check if there are any reports to parse. If it finds any reports that need parsing the parser starts and processes the reports.
You sent the report and the .done file before you created the report definition file. This caused the parser to go into a loop. We stopped the parser and you will have to re-send the report and .done files.
To get around this you need to assign a report to a group BEFORE parsing the report. Once you have created a report definition you can easily assign the report to a group, then FTP the report. If the report is assigned to something, it will not go to the default (USERS) group.
Unless the report is being generated differently, or is coming from a different source, there should be no need to change this setting in the report definition. So you will want to set it to your original "Top Of Form" value.
ePrint looks for the VERIFY STRING on the first page of the report (after getting rid of the junk pages). Since you are getting rid of two pages, we look on the third page for the verify string and the value "PAGE" is not on the page, so the verification fails. What you should be able to do is set junk pages to 1, and then "PAGE" should be found since it is on the what is now the first page (actually Page 2, but ePrint gets rid of 1). It looks as though you may have to adjust the location in the report definition, since "PAGE 2" doesn't appear to be in the same column as "PAGE 1."
You are receiving that message because there is a blank line before the first page delimiter (page break) on the report. When ePrint finds the blank line, it considers it a page. Then it finds the control character and treats that as a page break, and it handles the proceeding lines as page 2 data. To get the report to parse correctly, either define a junk page to get rid of the first page (page that contains just the blank line) or eliminate that blank line when the report is generated.
The report did not parse for two reasons -- the file name, and the missing .done file. The report name should match the report definition, which is fgrbdsc. Also, the parser will not start until there is a fgrbdsc.done file in the incoming directory. The auto FTP process will automatically rename the fgrbdsc_6302.lis to fgrbdsc and also create and FTP the fgrbdsc.done file.
There are duplicate page keys defined for this report. There are two DEPT at level 0.
That information is not logged. It is a warning only. When reports are created they will be created based on a certain number of lines per page. The number of lines per page is recorded in the report definition file. If you received this warning, I recommend that you increase the value for the number of lines per page in the report definition.
This message is not an error. This message was displayed because it took over one minute to parse a report (bbd120). When ePrint parses a report the repository is placed in a "locked" state. The parser will "wake" after one minute to see if there is something to do. Since the report was still parsing, ePrint displayed the message. This will continue until the parsing is complete. This condition only exists when a large report is sent. The report parsed successfully.
Change the number of lines to display to something like 999. You will see all the entries in the log. The display on the log files is the last x number of lines, where x is the number from the page (default is 100).
The parser got hung up on the report. This happened because the report definition was created while the report was already in the incoming directory with its corresponding .done file. In the future, you will want to set up the report definition before sending the files, or you will want to hold off on sending the .done file until you have the report definition created.
Here is one method that you can use. First copy the report definition from the original repository to the "new" one. In the "new" repository's report definition, change the "Top of Form" to Fixed_length and save these changes. Now go back to your original repository. Go to Stored Reports and download the "TEXT" version of the report you want to move. FTP the downloaded file to the "new" repository -- don't forget the .done file! The report will parse and it will now be in the "new" repository. Repeat the download of the TEXT and FTP steps for each instance of the report that you want to bring over. The only issue may be that the IP address of the desktop that you will be doing this from is not defined to the server as a valid IP address for FTP. Just let us know and we can make that change for you.
The DATA icon will only appear if you define CSV parsing for that report. When you use a report definition from one repository as a template for that same report in another repository, ePrint will just copy the report definition. If you want the DATA icon you can copy the CSV definition from the MVS repository as a template for the new FINDEVL CSV definition. The CSV definition is totally separate from the report definition.
In your report definition for FGRCTRL, you have two page keys defined and both are level 0. The page keys are for acct and account (both of these are used in FRS but not Banner). You may have these left from either the default or you copied the definition from an FRS report and didn't change it. Make sure you have the correct page defined because you are trying to use VBS and it won't work without the correct page key defined.
In the future, remember not to FTP a report file (or at least not the .done) until after the report definition has been completed.
The ePrint parser starts up every minute. I would suggest a delay of 5 minutes between the jobs. Run the first job and FTP the output; once in ePrint, wait a maximum of 1 minute for parser, another minute to execute and store the first job. With a 2-3 minute buffer you can be sure that the second job will run.
When loading security, you need to send at least four files: ZWOFFL (the output from ZBPS10), the authentication.done, FWOAFL (output from FBPS10, if FRS VBS is used) and vbs.done. Make sure you have all four and try it again.
The print queue name is the same as the Report FTP ID created when you initialized your repository. For example, if the Report FTP ID was "find," then the print queue in Banner would be "find." The instructions mention appending _ept. To follow this example through, the Report FTP ID would be find_ept as would the Banner print queue name. This information can be found in the Banner Interface document.
If you are using the script we delivered with Banner, you would be sending the reports to different "printers." You will be defining a "printer" for each Banner repository. Each instance of Banner will be a separate repository. So send the report to the correct "printer" and the script will send it to the proper repository.
These are important directories that you want to back up in order to facilitate a data recovery if necessary: /etc and /home. Anything taking up space in /home is important, so it is best to grab the whole thing. The /home directory holds all the ePrint data and the mysql data.
There is no way for you to selectively restore from the backup tape. Basically, the backup created is for disaster recovery situations and for full system restores in the event of something such as a hardware failure.
You sent the report and the .done file before you created the report definition file. This caused the parser to go into a loop. We stopped the parser and you will have to re-send the report and .done files.
In the report definition, you must set up the "Notification" section. If you specify an "EMAIL" address, when that report is parsed the email notification will be sent.
Are file names case sensitive?
Yes, file names are case sensitive. By default, if you do not specify a file name in your report definition, then ePrint assumes that the file name that will be sent over for the corresponding report definition will be lowercase. Otherwise, whatever you specify in the report definition for the "Filename" (upper or lowercase), is what you should name the file that you send to the ePrint server.
To get around this you need to assign a report to a group BEFORE parsing the report. Once you have created a report definition you can easily assign the report to a group, then FTP the report. If the report is assigned to something, it will not go to the default (USERS) group.
A non-Banner report is defined just like a Banner report. Nothing is different. A non-Banner report will need to be defined as an object in Banner and that object name must match the Report Definition name. In ePrint, if you leave the filename in the report definition blank, ePrint will expect the input filename to be the same as the Report definition name. This file is case sensitive.
Unless the report is being generated differently, or is coming from a different source, there should be no need to change this setting in the report definition. So you will want to set it to your original "Top Of Form" value.
ePrint looks for the VERIFY STRING on the first page of the report (after getting rid of the junk pages). Since you are getting rid of two pages, we look on the third page for the verify string and the value "PAGE" is not on the page, so the verification fails. What you should be able to do is set junk pages to 1, and then "PAGE" should be found since it is on the what is now the first page (actually Page 2, but ePrint gets rid of 1). It looks as though you may have to adjust the location in the report definition, since "PAGE 2" doesn't appear to be in the same column as "PAGE 1."
Yes, all reports go into the incoming directory of the repository. If no report definition uses that file name, then the file will remain in the incoming directory until you take some action -- either delete the file or rename it. A file in the incoming directory with no definition will cause ePrint to lock the repository. If you try to define the report any further processing will be halted. The recommendation would be to rename the file in the incoming directory, define the report, and then rename the file to its original name.
You are receiving that message because there is a blank line before the first page delimiter (page break) on the report. When ePrint finds the blank line, it considers it a page. Then it finds the control character and treats that as a page break, and it handles the proceeding lines as page 2 data. To get the report to parse correctly, either define a junk page to get rid of the first page (page that contains just the blank line) or eliminate that blank line when the report is generated.
Use the "Include Parameter" function to add the control parameter of your choice to the description of the report. For example, if you run frrgrnt for a selected chart-of-account (COAS), you can include this parameter in the description. When a user looks at the list they might see "Grant Report COAS=A". The include parameter is located on the File Verification and Report Title page at the bottom.
Currently, the report ID orders the reports. The ID is the name that was used to create the report definition. If you wanted to group those reports together, you would have to change the names of the report IDs (report definitons).
The parser got hung up on the report. This happened because the report definition was created while the report was already in the incoming directory with its corresponding .done file. In the future, you will want to set up the report definition before sending the files, or you will want to hold off on sending the .done file until you have the report definition created.
In your report definition for FGRCTRL, you have two page keys defined and both are level 0. The page keys are for acct and account (both of these are used in FRS but not Banner). You may have these left from either the default or you copied the definition from an FRS report and didn't change it. Make sure you have the correct page defined because you are trying to use VBS and it won't work without the correct page key defined.
The limit on the Report Definition Name is 18 characters. The limit for the Label and Description are both 60 characters.
How do I get a pdf file into ePrint?
Defining a pdf to be loaded into ePrint is similar to defining any other report in ePrint. Log in as an administrator; go to "Report Definitions" under "Report Tasks." "Create" a new definition. Once you are in the report definition wizard, enter a "Label" (optional), a "Description," and a "Filename" (optional). Next, toggle the "Input File Format" to "pdf." Then you will just need to FTP the report to the ePrint server with it's corresponding.done file. When FTPing a pdf to the ePrint server, be sure to use binary mode, otherwise the pdf may become corrupted during the file transfer.
Banner objects do have a character limit. If you are using the auto FTP you will need to follow the naming conventions in Banner. If it is a legacy report, in Banner you can assign an object name to the report, in ePrint create a report definition with the same object name, and in the report definition add the report file name. The report .done file that is FTP to ePrint will need to match the report configuration name or the Banner object name.
Yes, you can load reports that are generated using Word, Excel, and existing pdf files. Defining each of these reports requires different settings. Refer to your training manual, Section 5 - Reports for details.
Yes, you can import reports from Crystal Reports into ePrint. Refer to your training manual, Section 5 - Reports for details.
The CSV function of ePrint assumes that it is working with a text report. From the text report ePrint will create the comma-delimited file as output. Because of this ePrint will always display the pdf and TEXT icons. A simple solution is to send the file as straight data and have ePrint create the comma-delimited file. In this case, the users can see the raw data to see what was input.
As far as being prompted to save the file rather then just opening it, this is neither an ePrint nor an Excel issue. Rather, this is dependent on which Web browser is being used and how the browser is configured. When dealing with the CSV files, they should always save them to their hard drive first (right click and "save target as"), otherwise they will display incorrectly, just as you have described.
To get the DATA view option for a report, define a CSV definition. A report has to be defined first before you can do the CSV definition. Most likely a report that has columns of data are candidates for CSV. Define the columns of data that will be extracted to a comma-delimited dataset. You can review the help for defining CSV for a report. Once you have the CSV definition, the DATA icon will appear for all instances of the report.
Do not delete this repository! The ePrint demo repository is used as the template for all new repositories. This is why you don't want to delete it. You can hide it so users will not see it on the drop-down list. To hide it, go to the repository config, select the ePrint demo repository and click the EDIT button. At the bottom of the Repository Config page is the Hidden setting; set this to YES.
In the report definition, you must set up the "Notification" section. If you specify an "EMAIL" address, when that report is parsed the email notification will be sent.
In moving to Banner with ePrint there are a couple of things to keep in mind. First, ePrint will connect directly to Banner security, so there is no need for a security extract/load. This means that every Banner ID is a potential ePrint user. Next, you will be creating repositories for your Banner reports because different security is used in Banner compared to Plus.
When a user logs into their Banner repositories, they use their Banner ID/password. To access their Plus repositories, they use their Plus ID/password.
You can open ePrint in another browser window and compare the reports. This means that you would be logged in twice.
Yes, all reports go into the incoming directory of the repository. If no report definition uses that file name, then the file will remain in the incoming directory until you take some action -- either delete the file or rename it. A file in the incoming directory with no definition will cause ePrint to lock the repository. If you try to define the report any further processing will be halted. The recommendation would be to rename the file in the incoming directory, define the report, and then rename the file to its original name.
You have the "Hidden" flag on the Repositories page set to YES. This setting will hide the repository from the list. Just highlight NO and click Finished to change the setting.
There is no way for you to selectively restore from the backup tape. Basically, the backup created is for disaster recovery situations and for full system restores in the event of something such as a hardware failure.
This message is not an error. This message was displayed because it took over one minute to parse a report (bbd120). When ePrint parses a report the repository is placed in a "locked" state. The parser will "wake" after one minute to see if there is something to do. Since the report was still parsing, ePrint displayed the message. This will continue until the parsing is complete. This condition only exists when a large report is sent. The report parsed successfully.
Try changing the "Lines" setting to 999. That will display the first 999 lines of the log file. The default is 100, so that is all you are viewing.
When you create your new fiscal year repository using the report definition wizard, on the first page, you will find a "radio" button next to "Copy multiple report definitions as templates." Select the original repository from the drop-down list and then highlight the report definitions that you want to copy. You may use the Shift key to select a range or the CTRL key to select different individual definitions. Click the CREATE button and this will copy all of the selected report definitions to your new repository. Make individual adjustments to each report definition and you are all set.
No, the process of moving reports from one repository to another is not supported by ePrint. This is not a simple task, due in part to the databases behind ePrint and the many dependences that would need to be in place before the reports could be moved.
Here is one method that you can use. First copy the report definition from the original repository to the "new" one. In the "new" repository's report definition, change the "Top of Form" to Fixed_length and save these changes. Now go back to your original repository. Go to Stored Reports and download the "TEXT" version of the report you want to move. FTP the downloaded file to the "new" repository -- don't forget the .done file! The report will parse and it will now be in the "new" repository. Repeat the download of the TEXT and FTP steps for each instance of the report that you want to bring over. The only issue may be that the IP address of the desktop that you will be doing this from is not defined to the server as a valid IP address for FTP. Just let us know and we can make that change for you.
Can you assign an unlimited number of groups to a repository or is there a limit?
There is no limit on the number of groups you can have or the number of users within a group.
Yes, the Statistical Reports added in the 2.1 Release have this detail. For Banner-defined repositories, you will find report epruobj, Objects by User, and report eprouse, User by Object. For Plus repositories, look for report eprugrp, Groups/Reports by User, eprrgrp, Groups/Users by Report, and eprgusr, Users by Group.
The incoming log stated the following:
The DATA icon will only appear if you define CSV parsing for that report. When you use a report definition from one repository as a template for that same report in another repository, ePrint will just copy the report definition. If you want the DATA icon you can copy the CSV definition from the MVS repository as a template for the new FINDEVL CSV definition. The CSV definition is totally separate from the report definition.
We would like to move reports from one repository to another repository. How can I do that?
The process for copying reports from one repository to another is manual and a time-consuming task. It is not a simple file move; it also involves the movement of report records. Here are the steps involved for two different situations: first, for copying each instance of a report from one repository to another that does not contain any instances of the report, and second, for copying specific instances of report to a repository that contains other instances of the report 1. Copying each instance of a report from one repository to another that does not contain any instances of the report: a) Copy the folder structure b) Edit the control backup file for each instance of the report to reflect the new repository parameters c) Add the report index record(s) to the repository report_index table d) Copy or import the report page data into the new repository e) If VBS is applied to the report, copy or import the VBS data into the new repository f) Add the report to the report authorization table g) Copy the report configuration file to the new repository 2. Copying specific instances of report to a repository that contains other instances of the report: a) Copy the folder structure b) Edit the control backup file for each instance of the report to reflect the new repository parameters c) Add the report index record(s) to the repository report_index table d) Copy or import the report page data into the new repository e) If VBS is applied to the report, copy or import the VBS data into the new repository.
Is it possible to have multiple FTP users for one repository?
No, there is only one FTP User/Password per repository, but you may use the user/password from multiple locations to ePrint. I'm assuming you want to send reports from more than one location? If so, they can all use the same FTP User ID. This should work fine as long as they are not all sending the same report at the same time.
If you you establish the FTP connection from a PC, you will use the FTP ID/password (from the repository initialization) and send the pdf file and the .done file. When sending a pdf file, send it in binary mode not ASCII. The ePrint server will need the IP address of the PC defined so the FTP transfer can take place. The process of sending a pdf file is the same as sending any other report to ePrint.
When loading security into a repository you need at least three files for the security parser to run: the authentication file (usually ZWOFFL), authentication.done (empty file), and vbs.done (also empty file). If you have defined value-based security (VBS) elements in your security definition, you also need to send those files (ex., FWOAFL for accounts in FRS), before the vbs.done file.
Yes, the User ID will be left in the groups in which they where originally in. Otherwise, you would have to re-create all the groups every time you loaded them via BATCH update. Having the User IDs stay assigned to the groups is only a problem if you re-use the Operator ID for a different user.
If you are using the script we delivered with Banner, you would be sending the reports to different "printers." You will be defining a "printer" for each Banner repository. Each instance of Banner will be a separate repository. So send the report to the correct "printer" and the script will send it to the proper repository.
There is no way for you to selectively restore from the backup tape. Basically, the backup created is for disaster recovery situations and for full system restores in the event of something such as a hardware failure.
The email will go to all users who have access to the report (and have their email addresses in ePrint). Even if there are no pages for them to view, they would get an email. ePrint does not check every user's report access to see if there is anything for them to see, it just knows that the report is ready.
One Plus school added the user's email address to the ZCFILE. They used a couple of fields that they did not use in ZSS and made it email address. They added this field to the extract file and to the security definition in ePrint so they could continue to use Batch mode update. With Batch mode update you can maintain your users with ZSS and ePrint reflects those changes.
After further discussion, we concluded that an update mode of "Both" would work for you. This will keep the email addresses in ePrint. The drawback here is that when you delete a user from ZSS, you must also delete the user from ePrint.
Another solution would be to include all the users email addresses, separated by commas on the "Notification" page of the report definition. The drawback here is that you would need to add/delete email addresses as the list of users changes.
>Each of these solutions requires some change on your part. Select the one that best works for you.
In moving to Banner with ePrint there are a couple of things to keep in mind. First, ePrint will connect directly to Banner security, so there is no need for a security extract/load. This means that every Banner ID is a potential ePrint user. Next, you will be creating repositories for your Banner reports because different security is used in Banner compared to Plus.
When a user logs into their Banner repositories, they use their Banner ID/password. To access their Plus repositories, they use their Plus ID/password.
When you change the accounts that an operator has access to from one fiscal year to another, this requires a new repository in ePrint. The security load program (FBPS10) is looking at VBS based on the fiscal year in FRS. That is why the users cannot see their "old" accounts on the reports, and this will be true for all instances of the report.
You will need to run FBPS10 for FY04 and reload security in your repository. Next, create a FY05 repository and load your FY05 security. Then copy the report definitions from your "old" FY04 repository to your new FY05 repository. To copy the report definitions, log on to the FY05 repository and go to the report definition wizard. Use the "Copy multiple report definition files as templates " function and select the report definitions that you want to copy.
You are now ready to start loading the reports into your FY05 repository. Users will need to be in the correct fiscal year to see the right accounts.
The reason that you can't FTP to the server is because the server will only allow certain IP addresses to FTP to it. If you send us the IP address of the machine where you FTP from, we can add that to the server.
How can I make sure that the fwoafl file has processed properly in the security loader?
As long as it is defined in your security setup, ePrint will require that file. If it's not there, then the parser fails and you get the error message, "file not found." Otherwise, if the parser is successful, then all is good.
When loading security into a repository you need at least three files for the security parser to run: the authentication file (usually ZWOFFL), authentication.done (empty file), and vbs.done (also empty file). If you have defined value-based security (VBS) elements in your security definition, you also need to send those files (ex., FWOAFL for accounts in FRS), before the vbs.done file.
The message that you received on the FTP step, zwoffl: Permission denied on server (Overwrite), means that the ZWOFFL file already exists in the security incoming directory of this repository. To move the new ZWOFFL file into the correct repository/directory, delete the existing ZWOFFL file in ePrint. To do this: 1. Log in as the Administrator
2. Go to Security Incoming, located under the File Maintenance heading
3. On the Security Incoming Directory page, highlight the file (ZWOFFL)
4. Click the delete button. You will be asked to confirm the delete. Click OK
The difference between the four Banner security methods is in how page level security is applied. Banner Finance will pull a user's security elements from the FOMPROF form. HR will pull a user's security elements from the form PTRUSR. Currently, Student and General do not apply page level security, but we plan to incorporate Student page level security into ePrint.
If the "Update Mode" in your Security definition is set to "Both," then you would need to delete those users from the repository via ePrint. If "Update Mode" is set to "Batch," then those users would be deleted from ePrint when security is reloaded (by running and FTP'ing the output files from ZBPS10 and APS10). The reason that "Update Mode" may be set to Both, is to allow you to create users directly in ePrint (using the User create function).
The NO_OVERLAY security update option works the same as BOTH option. With either of these security update options, ePrint does not delete users when a batch file is used because you can also create users directly into ePrint with this setting.
What is the maximum length that ePrint will accept for a password?
ePrint will accept a password field as long as you need it. Define the location and size of the password in your security definition.
Yes, you can create your own VBS file for that report. This will not have any impact on any other report to which those users have access. Your VBS file will be made up of the Header record, which will contain the fiscal year (not used in SIS), element number (this will match a value you entered as the Verify string in your security definition of this element), the length of the element, and the number of times it will occur on the detail record.
Following the Header record your Detail records contain the Operator IDs and the values of the element to which this operator has access. An operator may have more than one detail record.
Are you receiving this error when you try to open the report? The page keys defined in the report definition must match the VBS values that you use in the security VBS setup. In other words, in the report definition you will either have to use "sisuser" for the page key value, or use "user" in the security VBS setup.
As for the reports sitting in the Security Incoming Directory, the security loader also needs an "authentication.done" file. Once it is there, the security files should process.
The BOTH security option will only "append" new data and anything that has changed. It will not remove any records. For example, say you have Operator 1234 on the mainframe and load that ID into ePrint. Then you delete Operator 1234 in ZSS and re-load security in ePrint. Operator 1234 will remain in ePrint.
In BATCH mode for the above example, when you re-load security after deleting operator 1234 in ZSS, it will be removed because ePrint is in a "replace" mode with BATCH mode.
The user will need to be set up as an Internet Native Banner user if you are going to be using Self-Service. If you refer to page 7 of the ePrint Banner Interface documentation, you will see that for the Oracle ID of rlocke, they have an INB ID of 111111111. They will log into Web Tailor with 111111111 but their Oracle ID is used to process their Finance security. ePrint will be using the Oracle ID, just as Self-Service Finance does behind the scenes to process security.
If you or your group would like to shut the machine down yourself, here are the instructions. 1) Log in as the root user
2) At the prompt type: SHUTDOWN NOW
3) When the screen stops scrolling, power off the server
The message that you received on the FTP step, zwoffl: Permission denied on server (Overwrite), means that the ZWOFFL file already exists in the security incoming directory of this repository. To move the new ZWOFFL file into the correct repository/directory, delete the existing ZWOFFL file in ePrint. To do this: 1. Log in as the Administrator
2. Go to Security Incoming, located under the File Maintenance heading
3. On the Security Incoming Directory page, highlight the file (ZWOFFL)
4. Click the delete button. You will be asked to confirm the delete. Click OK
Currently, the report ID orders the reports. The ID is the name that was used to create the report definition. If you wanted to group those reports together, you would have to change the names of the report IDs (report definitons).
There is only one copy of the report. ePrint will create a pdf file if it is needed, but it is only a temporary file.
You can use this format to set the date: date -s HH:MM:SS (H = Hour, M = Minute, S = Seconds). For example, if it was 1:36 PM you would use: date -s 13:36:00. After that, you may want to synchronize the hardware clock: hwclock -systohc
This message is not an error. This message was displayed because it took over one minute to parse a report (bbd120). When ePrint parses a report the repository is placed in a "locked" state. The parser will "wake" after one minute to see if there is something to do. Since the report was still parsing, ePrint displayed the message. This will continue until the parsing is complete. This condition only exists when a large report is sent. The report parsed successfully.
The ePrint parser starts up every minute. I would suggest a delay of 5 minutes between the jobs. Run the first job and FTP the output; once in ePrint, wait a maximum of 1 minute for parser, another minute to execute and store the first job. With a 2-3 minute buffer you can be sure that the second job will run.
Use the Statistical Reports section of the administrative Interface to generate a report that can display this information. You can get summary and detail information about who is looking at which reports. Report eprusgs will give you a summary of activity on a report. Report eprusgd will display detail information on each instance of a report, which includes who viewed it, and the date and time it was viewed.
To get around this you need to assign a report to a group BEFORE parsing the report. Once you have created a report definition you can easily assign the report to a group, then FTP the report. If the report is assigned to something, it will not go to the default (USERS) group.
Yes, currently there is no way to rename a group in ePrint. You should be able to create a new group and assign it the same users as the old group. You also should be able to do the same with reports since the reports assigned to a group are based on the name of the report, and not based on each individual instance of the report.
Can you assign an unlimited number of groups to a repository or is there a limit?
There is no limit on the number of groups you can have or the number of users within a group.
Yes, the Statistical Reports added in the 2.1 Release have this detail. For Banner-defined repositories, you will find report epruobj, Objects by User, and report eprouse, User by Object. For Plus repositories, look for report eprugrp, Groups/Reports by User, eprrgrp, Groups/Users by Report, and eprgusr, Users by Group.
Yes, the User ID will be left in the groups in which they where originally in. Otherwise, you would have to re-create all the groups every time you loaded them via BATCH update. Having the User IDs stay assigned to the groups is only a problem if you re-use the Operator ID for a different user.
You are correct in that you need to load the users email address into ePrint in order to have it send out a notification of the reports. Because you have the update mode set to BATCH, if you manually entered the email addresses, they would be "wiped out" the next time security was loaded. The best solution is to take the output file from ZBPS10 (ZWOFFL) and add the email addresses to the security extract from ZBPS10. This could be time-consuming, depending on the number of email addresses that you are loading. A couple of schools have used a field in the ZSFILE that they were not using and made it email address, then added a line of code in ZBPS10 to move the email to the extract file.
If a user tries to login and is not successful after five attempts, that ID will be locked. To unlock the ID, go to the "Users" page on the Administrator Interface, type in the ID (or use the clipboard to find the ID). Click the "edit" button and click the "unlock" button. The user will now be able to log in.
In moving to Banner with ePrint there are a couple of things to keep in mind. First, ePrint will connect directly to Banner security, so there is no need for a security extract/load. This means that every Banner ID is a potential ePrint user. Next, you will be creating repositories for your Banner reports because different security is used in Banner compared to Plus.
When a user logs into their Banner repositories, they use their Banner ID/password. To access their Plus repositories, they use their Plus ID/password.
There is only one Super Administrator ID in ePrint. More than one person can use that ID/Password.
The user will need to be set up as an Internet Native Banner user if you are going to be using Self-Service. If you refer to page 7 of the ePrint Banner Interface documentation, you will see that for the Oracle ID of rlocke, they have an INB ID of 111111111. They will log into Web Tailor with 111111111 but their Oracle ID is used to process their Finance security. ePrint will be using the Oracle ID, just as Self-Service Finance does behind the scenes to process security.
There is only one copy of the report. ePrint will create a pdf file if it is needed, but it is only a temporary file.
Have him clear the cache in his browser and try again. This normally will resolve the problem.
You can open ePrint in another browser window and compare the reports. This means that you would be logged in twice.
Answer
Currently, the report ID orders the reports. The ID is the name that was used to create the report definition. If you wanted to group those reports together, you would have to change the names of the report IDs (report definitions).
The report contains only one page of data and you have it defined with the last page as a junk page. ePrint is removing the last page, which in this case happens to also be the first page, and this leaves you with no pages. Remove the junk page and you should be all set.
Try changing the "Lines" setting to 999. That will display the first 999 lines of the log file. The default is 100, so that is all you are viewing.
How would I darken a report to make it easier to read?
To darken the print and display of a report, use the LANDSCAPE_BOLD setting in the Page Format of the report definition. After making this change you would need to re-parse the report. This will only effect reports parsed after the change.
In looking at the reports, they are filed under 09/04/2003 but the report date is 02/09/04. When I compared these reports against the last "good one" (1/29/04), I noticed that the report is different. The "good" reports have on the heading line, DATE RUN: nn/nn/nn; the reports in question had, DATE:nn/nn/nn.
The date is in a different place, that's why they are not listed under the correct date. Change the date setting on the report definition in ePrint or on the heading of the report.
The 65,536 line is the limit Excel can accept. The only workaround would be to split the report. With VBS the number of people who can see the entire report should be limited. The main question would be, is someone who has access to all the information likely to download to Excel?
The CSV function of ePrint assumes that it is working with a text report. From the text report ePrint will create the comma-delimited file as output. Because of this ePrint will always display the pdf and TEXT icons. A simple solution is to send the file as straight data and have ePrint create the comma-delimited file. In this case, the users can see the raw data to see what was input.
If you are using Internet Explorer as your browser, right mouse click, save target as, and save the file to your desktop (or wherever you want). Then go to the file and open it, this should open Excel and display the report in CSV format. If you use the primary mouse button to click the "Data" icon, this will cause Excel to open within the browser and not perform the CSV processing.
As far as being prompted to save the file rather then just opening it, this is neither an ePrint nor an Excel issue. Rather, this is dependent on which Web browser is being used and how the browser is configured. When dealing with the CSV files, they should always save them to their hard drive first (right click and "save target as"), otherwise they will display incorrectly, just as you have described.
Define the report with a junk page of type = LINES and Line = 1. ePrint will ignore the first line of the report. A number of the FAM reports place a page break before the first page, which causes problems in ePrint. This is not a "known issue," but just the way FAM reports are formatted. If the reports are printed, there is no problem. This is something that you will need to be aware of when defining FAM reports to ePrint. The FAM ActionLine looked into a change, but the effort was too great and would affect all of FAM.
To get the DATA view option for a report, define a CSV definition. A report has to be defined first before you can do the CSV definition. Most likely a report that has columns of data are candidates for CSV. Define the columns of data that will be extracted to a comma-delimited dataset. You can review the help for defining CSV for a report. Once you have the CSV definition, the DATA icon will appear for all instances of the report.
It sounds like they losing their login session. Make sure their browsers are set to accept cookies. Also make sure their "Privacy Settings" are not too high. Anything higher than "Medium" may cause problems such as the one you are describing.
When you change the accounts that an operator has access to from one fiscal year to another, this requires a new repository in ePrint. The security load program (FBPS10) is looking at VBS based on the fiscal year in FRS. That is why the users cannot see their "old" accounts on the reports, and this will be true for all instances of the report.
You will need to run FBPS10 for FY04 and reload security in your repository. Next, create a FY05 repository and load your FY05 security. Then copy the report definitions from your "old" FY04 repository to your new FY05 repository. To copy the report definitions, log on to the FY05 repository and go to the report definition wizard. Use the "Copy multiple report definition files as templates " function and select the report definitions that you want to copy.
You are now ready to start loading the reports into your FY05 repository. Users will need to be in the correct fiscal year to see the right accounts.
When you create your new fiscal year repository using the report definition wizard, on the first page, you will find a "radio" button next to "Copy multiple report definitions as templates." Select the original repository from the drop-down list and then highlight the report definitions that you want to copy. You may use the Shift key to select a range or the CTRL key to select different individual definitions. Click the CREATE button and this will copy all of the selected report definitions to your new repository. Make individual adjustments to each report definition and you are all set.