From owner-sqr-users@list.iex.net Thu Jul 1 02:08:57 1999 Date: Thu, 1 Jul 1999 16:55:51 +1000 From: Adrian Clayfield Subject: Re: Is there anyway to determine what panel group was used to launch an sqr without creating a specialized runcntl record? Hi, Can you add LASTUPDDTM to your parameter table, then select PNLGRPNAME from PSPNLGRPDEFN where LASTUPDDTM matches it, or something along those lines.... ----------------------------------------------------- SGRUG, I have an sqr where I want to due conditional processing based on what panel group launched the sqr. I have a parameter table and don't want to create a run control record. I can select the parameter based on the panel group but can I get the panel group name from within SQR, if yes how? Pamela From owner-sqr-users@list.iex.net Thu Jul 1 06:01:13 1999 Date: Thu, 1 Jul 1999 06:42:04 EDT From: Steffon Johnson Subject: Re: Is there anyway to determine what panel group was used to lau... That would only tell you the last operator id that updated the panel group defn. You may, however, add the information to your run control table/file by capturing the information via P'Code on SaveEdit, or SavePostChange via SQLExec() (last choice, though). Email me directly and I'll give you my phone number and we talk real-time. HTH, Steffon From owner-sqr-users@list.iex.net Thu Jul 1 07:32:27 1999 Date: Thu, 1 Jul 1999 06:59:57 -0500 From: "Wendel, Robbi" Subject: Re: Print last page I apologize if this is something that you have already addressed or answered previously, but have you considered trying to use NEW-REPORT instead? It resets the internal page counter and permits multiple reports from same SQR. I didn't backtrack to look at all information regarding this posting to date, so you may have already addressed this or ruled this out. Have a great day, Robbi -----Original Message----- From: Kris Narravula [mailto:kris_narravula@HOTMAIL.COM] Sent: Wednesday, June 30, 1999 3:57 PM To: Multiple recipients of list SQR-USERS Subject: Re: Print last page Hi John, Sherry and Every Body, I got the same problem and wanted to post it. At the same time I saw the request on the list and looking for the outcome. I am getting the following error when I use LAST-PAGE command to print the last page number of the report on every page header as 'page 1 of 99' and run it to a printer from PeopleSoft. It works fine when I run the report to a file from the same PeopleSoft. (SQR 6002) Cannot open the printer file: \\cairo\infosrvs.spf (2): No such file or directory When I remove the LAST-PAGE command and run the report it works fine with out any error to the file as well as to the printer from PeopleSoft. We are on Oracle 7.3.4.3.1 and is on HPUX 10.20 & WinNT 4.0 File Server, SQR 4.3.2 PeopleSoft HRMS 7.50.00.000 PeopleTools 7.54.10 I am sorry, I may be giving a bit of inconvenience to the only SQR users. I am posing this here as similar issue is in discussion. Any body has any clues. Thanks in advance Kris ----- Original Message ----- From: Sherry Jin Sent: Wednesday, June 30, 1999 12:55 PM Subject: Re: Print last page John, Thanks for the response. The problem is resolved if I add -printer:WP into the SQR flag in config manager and specify file as the output destination. What happens is that whenever printer (Say LPT2) is selected as the output, peoplesoft generates -flpt2 into the process parameter. I believe "last-page" tries to generate a temp buffer file and considers lpt2 as the output directory/file. Sherry At 03:02 PM 6/30/99 -0400, John Milardovic wrote: >Do you mean 'print-direct'? or -printer:WP? or are you piping to the printer >in UNIX? > >If print-direct the problem might be that print-direct sends output directly >to the printer (i.e.. bypassing the SQR buffer) and so SQR can't calculate >the number of pages in the report. > >John Milardovic > >> -----Original Message----- >> From: Sherry Jin [SMTP:sjin@WINSTAR.COM] >> Sent: Wednesday, June 30, 1999 1:54 PM >> To: Multiple recipients of list SQR-USERS >> Subject: Print last page >> >> I am trying to use last-page to print out the total numbers of pages on >> each page. It works when I use file as the output destination, but >> receives >> error message 'Error reading the printer file (22) Invalid argument' when >> printer is used as the output destination. >> >> This is what I added to the code: >> >> page-number (1,1) 'Page ' >> last-page () ' Of ' >> >> Adding command last-page causes the error when output is printer. >> Has anyone been able to invoke last-page and send the output directly to >> printer? >> >> Thanks for any help, >> Sherry > > From owner-sqr-users@list.iex.net Thu Jul 1 16:55:39 1999 Date: Thu, 1 Jul 1999 10:02:47 -0400 From: "Morgan, Michael" Subject: Re: [psusers] Employee name format With rubber gloves. -----Original Message----- From: Kenny Melton [SMTP:KMELTO1@TANDY.COM] Sent: Wednesday, June 30, 1999 6:15 PM To: Multiple recipients of list SQR-USERS Subject: Re: [psusers] Employee name format Better yet, how would you handle The Artist Formerly Known As Prince? Kenny -----Original Message----- From: Gracen Duffield [mailto:gduffiel@TDHCA.STATE.TX.US] Sent: Wednesday, June 30, 1999 4:59 PM To: Multiple recipients of list SQR-USERS Subject: Re: [psusers] Employee name format When I was born, my parents decided that since I was a girl, I only needed two names. That way, when I got married, I would add my husband's name and then I would have a complete name. Since then, the seeds of my feminist rebellion have slowly twisted and turned on the injustice of not having a middle name. Why should my brother get a middle name, but not me? At my highschool graduation, the person who graduated in front of me had four!! names ( Megan Campbell Fitzhugh Wallace -- figure out which o' them is the "middle" name ). I have spent hours obsessing about this, but now, having read Jim's post, my spirit is lifted. Maybe my parents were on to something. I don't know, but when the rest of you don't get paid because your names were accidentally wiped out of the system by someone trying to fix the middle initial problem (MIP), my money will be sittin' pretty in the bank. You know, maybe we'd all be better off (albeit, possibly unemployed) if users weren't actually allowed to enter any data in the system. Barring that, can I see a show of hands for the "Buchanan ID" proposed last week ..... Gracen Duffield Texas Department of Housing and Community Affairs 475-3839 -----Original Message----- From: Jim Hardesty [mailto:jhardest@lmberry.com] Sent: Wednesday, June 30, 1999 2:50 PM To: psusers@egroups.com Subject: [psusers] Employee name format Here's a fun problem: PeopleSoft defines employee name as Last,First MI. (one letter MI). And many of us have found that PeopleSoft has a problem with the rotate name routine (rotname3.sqc) because it will not correctly handle names with spaces in the first name. 'Leone-Chipman,Mona Lisa T' comes out as last=Leone-Chipman, first = Mona and MI=L. and it ignores the T altogether. (We modified rotate name to correctly look for space and initial in the last two characters of name and whatever remains is first name). But here's a new one. I just found out that our users have been entering full middle names for some time. So we apparently have hundreds of employees with names like 'Wallis,Brandy Lee' instead of 'Wallis,Brandy L'. Which is kinda scary. Because now we have no way to get middle initial for those people. There is no way now to know if 'Wallis,Brandy Lee' has a middle name of Lee or a first name of Brandy Lee with no middle name (it happens). Wow. Big fun. The payroll manager says that they have been hiring people like this for years (ouch!) because that is the name on the Social Security Card. Uh oh. So if Betsy Ann Smith shows me a social security card, I have no way of knowing if she has a middle name or not. Is she "Betsy Ann" Smith or "Betsy" "Ann" Smith? Or worse, Mona Lisa Teresa Leone-Chipman. Is her middle name "Teresa" or is it "Lisa Teresa"? You could pretty much fix the rotate name routines to grab last name and shove everything else into first name by looking for the comma. This would work fine for JRs, IIs, etc. But there wouldn't be any way to get middle initial. What would you do, grab the first letter off the last 'word' in the first name if they have more than one 'word' in the first name? And what if someone has two first names and no middle name? Or one first name and two middle names? Yuk. So, what to do...what to do? The SQR programming isn't so much an issue. I doubt there is a single time we NEED middle initial so it is a moot point. Although who knows on some tax interfaces? PeopleCode could be an issue, but probably not. The real issue is functionally, what the heck should we be putting in the Name field? Inconsistent data is not good. We can't have 1/2 our employee names with a middle name and 1/2 with only initial. But what if we are required to use the Social Security Card name and old people like me have a card that says "James E Hardesty"? But maybe my wife has a new card that says "Joanne Lynn Hardesty"? This has "endless fiasco" written all over it. Before you laugh, go run a query and see if you have anybody out there with a bad name... jim ------------------------------------------------------------------------ eGroups Spotlight: "Egg and Egg Products" - There's more to eggs than eating them for breakfast! If you are a producer or a user this group is for you. http://clickhere.egroups.com/click/114 eGroups.com home: http://www.egroups.com/group/psusers http://www.egroups.com - Simplifying group communications From owner-sqr-users@list.iex.net Thu Jul 1 16:50:58 1999 Date: Thu, 1 Jul 1999 09:58:19 -0700 From: Kris Narravula Subject: Re: Print last page Robbi, I am not trying to create multiple reports and I am also not trying to do any manipulation of Page Numbers, etc. My question is very simple, I am getting the error while I am trying to run the report to the printer via PeopleSoft with SQR's LAST-PAGE command in the report. It works fine when I run it to the file from the same PeopleSoft Menu. The error I am getting is (SQR 6002) Cannot open the printer file: \\cairo\infosrvs.spf (2): No such file or directory It is not addressed yet. Thanks in advance. Kris ----- Original Message ----- From: Wendel, Robbi Sent: Thursday, July 01, 1999 4:59 AM Subject: Re: Print last page I apologize if this is something that you have already addressed or answered previously, but have you considered trying to use NEW-REPORT instead? It resets the internal page counter and permits multiple reports from same SQR. I didn't backtrack to look at all information regarding this posting to date, so you may have already addressed this or ruled this out. Have a great day, Robbi -----Original Message----- From: Kris Narravula [mailto:kris_narravula@HOTMAIL.COM] Sent: Wednesday, June 30, 1999 3:57 PM To: Multiple recipients of list SQR-USERS Subject: Re: Print last page Hi John, Sherry and Every Body, I got the same problem and wanted to post it. At the same time I saw the request on the list and looking for the outcome. I am getting the following error when I use LAST-PAGE command to print the last page number of the report on every page header as 'page 1 of 99' and run it to a printer from PeopleSoft. It works fine when I run the report to a file from the same PeopleSoft. (SQR 6002) Cannot open the printer file: \\cairo\infosrvs.spf (2): No such file or directory When I remove the LAST-PAGE command and run the report it works fine with out any error to the file as well as to the printer from PeopleSoft. We are on Oracle 7.3.4.3.1 and is on HPUX 10.20 & WinNT 4.0 File Server, SQR 4.3.2 PeopleSoft HRMS 7.50.00.000 PeopleTools 7.54.10 I am sorry, I may be giving a bit of inconvenience to the only SQR users. I am posing this here as similar issue is in discussion. Any body has any clues. Thanks in advance Kris ----- Original Message ----- From: Sherry Jin Sent: Wednesday, June 30, 1999 12:55 PM Subject: Re: Print last page John, Thanks for the response. The problem is resolved if I add -printer:WP into the SQR flag in config manager and specify file as the output destination. What happens is that whenever printer (Say LPT2) is selected as the output, peoplesoft generates -flpt2 into the process parameter. I believe "last-page" tries to generate a temp buffer file and considers lpt2 as the output directory/file. Sherry At 03:02 PM 6/30/99 -0400, John Milardovic wrote: >Do you mean 'print-direct'? or -printer:WP? or are you piping to the printer >in UNIX? > >If print-direct the problem might be that print-direct sends output directly >to the printer (i.e.. bypassing the SQR buffer) and so SQR can't calculate >the number of pages in the report. > >John Milardovic > >> -----Original Message----- >> From: Sherry Jin [SMTP:sjin@WINSTAR.COM] >> Sent: Wednesday, June 30, 1999 1:54 PM >> To: Multiple recipients of list SQR-USERS >> Subject: Print last page >> >> I am trying to use last-page to print out the total numbers of pages on >> each page. It works when I use file as the output destination, but >> receives >> error message 'Error reading the printer file (22) Invalid argument' when >> printer is used as the output destination. >> >> This is what I added to the code: >> >> page-number (1,1) 'Page ' >> last-page () ' Of ' >> >> Adding command last-page causes the error when output is printer. >> Has anyone been able to invoke last-page and send the output directly to >> printer? >> >> Thanks for any help, >> Sherry > > From owner-sqr-users@list.iex.net Thu Jul 1 14:32:10 1999 Date: Thu, 1 Jul 1999 11:22:37 -0700 From: Pankaj Bedekar Subject: SQL-SERVER how to run stored procedures or SELECT INTO statement in SQL paragraph This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BEC3EE.B257DB0C Content-Type: text/plain; charset="iso-8859-1" I am using MS SQL-SERVER 6.5 AND SQR 3. I need to create a table on the fly using a SELECT statement. I tried using SELECT INTO in BEGIN-SQL ...END-SQL block but it never executed the statement. I created a stored procedure which does the same but now I cannot execute the stored procedure using EXECUTE or using 'BEGIN-SQL...END-SQL' anyone have done this before ? plea let me know if anyone have more info. on this . Thank you, Pankaj ------_=_NextPart_001_01BEC3EE.B257DB0C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SQL-SERVER how to run stored procedures or SELECT INTO statement = in SQL paragraph

I am using MS SQL-SERVER 6.5 AND SQR = 3. I need to create a table on the fly using a SELECT statement.
I tried using SELECT INTO in = BEGIN-SQL ...END-SQL block but it never executed the statement.
I created a stored procedure which = does the same but now I cannot execute the stored procedure using = EXECUTE
or using 'BEGIN-SQL...END-SQL' =

anyone have done this before ? plea = let me know if anyone have more info. on this .
 
Thank you,

Pankaj

------_=_NextPart_001_01BEC3EE.B257DB0C-- From owner-sqr-users@list.iex.net Thu Jul 1 14:05:38 1999 Date: Thu, 1 Jul 1999 11:46:22 -0700 From: Joe Subject: Selecting a date that is 4 weeks prior to report date Hi all, I need to select Date_A from a record where Date_A is no more than 4 weeks prior to Date_Report. The logic is "select Date_A from Record_A where Date_A = Date_Report + 28 days" What's the most efficient way to do this? Thanks in Advance ~~ JEJ ~~ ;{) -------------------------------------------------------- $14.95 Unlimited Internet Access, http://www.surfree.com From owner-sqr-users@list.iex.net Thu Jul 1 17:09:13 1999 Date: Thu, 1 Jul 1999 17:01:49 -0400 From: "Sarabudla, Raji R." Subject: Re: Selecting a date that is 4 weeks prior to report date Hi Joe, Is the Date_ Report is Current Date ? If it is Current date, the following method is easy. Declare a date variable in Setup section and Use the dateadd function to add or subtract the no. of days. And use the newdate in your where clause. Make sure the date format is the same with your Database date format. You can accomplish the Date from the record not more than 4 weeks prior to the Report_Date (Current Date) with following example Ex: Begin-setup Declare-variable Date $datenew,$date_report End-delcare End-setup Begin-program Do main-processing End-program Begin-procedure main-processing -- if Date_report is Current_Date, use datenow() function let $Date_report = datenow() Let $datenew = dateadd($Date_Report, 'day',-28) - subtracts 4 weeks from current date Begin-select Date_A from Record_A where Date_A >= $datenew -- Make sure the Date format here. If necessary format it, -- as ex: TO_DATE($datenew,'DD-MON-YY') or whatever end-select end-proceduire Hope this helps raji ---------- From: Joe [SMTP:jejohn1216@SURFREE.COM] Sent: Thursday, July 01, 1999 2:46 PM To: Multiple recipients of list SQR-USERS Subject: Selecting a date that is 4 weeks prior to report date Hi all, I need to select Date_A from a record where Date_A is no more than 4 weeks prior to Date_Report. The logic is "select Date_A from Record_A where Date_A = Date_Report + 28 days" What's the most efficient way to do this? Thanks in Advance ~~ JEJ ~~ ;{) -------------------------------------------------------- $14.95 Unlimited Internet Access, http://www.surfree.com From owner-sqr-users@list.iex.net Thu Jul 1 16:55:55 1999 Date: Thu, 1 Jul 1999 15:15:51 -0600 From: Tim Green Subject: Re: SQL-SERVER how to run stored procedures or SELECT INTO statement in SQL paragraph --0__=pcU9TRtkwC7FuWpUrtBjlFVXge4SWxMIFi2Hhj3hJPMbHJrfve6iUSQZ Content-type: text/plain; charset=us-ascii Content-Disposition: inline I don't have enough info about your situation to be sure, but this sounds familiar. Are you doing the "Select... Into" into a temporary table, of the #tablename variety? You sure it's not being executed? SQR will run SQL statements on multiple connections to the server, and a temporary table is only visible on the connection it was created on. Also, temp tables created within stored procedures are dropped when the stored procedure terminates. Try using the -Cn parameters on the Begin-SQL line that creates the table, and on any Begin-Select or Begin-SQL paragraphs that reference it. And of course, verify that the Begin-SQL paragraph is being executed within your program flow with a display or show statement just before the Begin-SQL paragraph. Good luck, Tim Pankaj Bedekar on 07/01/99 02:22:37 PM Please respond to SQR-USERS@list.iex.net To: Multiple recipients of list SQR-USERS cc: (bcc: Tim Green/HWRD/ASG_Louisville/NAD) Subject: SQL-SERVER how to run stored procedures or SELECT INTO statement in SQL paragraph I am using MS SQL-SERVER 6.5 AND SQR 3. I need to create a table on the fly using a SELECT statement. I tried using SELECT INTO in BEGIN-SQL ...END-SQL block but it never executed the statement. I created a stored procedure which does the same but now I cannot execute the stored procedure using EXECUTE or using 'BEGIN-SQL...END-SQL' anyone have done this before ? plea let me know if anyone have more info. on this . Thank you, Pankaj --0__=pcU9TRtkwC7FuWpUrtBjlFVXge4SWxMIFi2Hhj3hJPMbHJrfve6iUSQZ Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-transfer-encoding: base64 Content-Description: Internet HTML PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjQ0OC4wIj4NCjxUSVRMRT5TUUwtU0VS VkVSIGhvdyB0byBydW4gc3RvcmVkIHByb2NlZHVyZXMgb3IgU0VMRUNUIElOVE8gc3RhdGVtZW50 IGluIFNRTCBwYXJhZ3JhcGg8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJ WkU9MiBGQUNFPSJBcmlhbCI+SSBhbSB1c2luZyBNUyBTUUwtU0VSVkVSIDYuNSBBTkQgU1FSIDMu IEkgbmVlZCB0byBjcmVhdGUgYSB0YWJsZSBvbiB0aGUgZmx5IHVzaW5nIGEgU0VMRUNUIHN0YXRl bWVudC48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JIHRyaWVkIHVzaW5n IFNFTEVDVCBJTlRPIGluIEJFR0lOLVNRTCAuLi5FTkQtU1FMIGJsb2NrIGJ1dCBpdCBuZXZlciBl eGVjdXRlZCB0aGUgc3RhdGVtZW50LjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp YWwiPkkgY3JlYXRlZCBhIHN0b3JlZCBwcm9jZWR1cmUgd2hpY2ggZG9lcyB0aGUgc2FtZSBidXQg bm93IEkgY2Fubm90IGV4ZWN1dGUgdGhlIHN0b3JlZCBwcm9jZWR1cmUgdXNpbmcgRVhFQ1VURSA8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5vciB1c2luZyAnQkVHSU4tU1FM Li4uRU5ELVNRTCcgPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi PmFueW9uZSBoYXZlIGRvbmUgdGhpcyBiZWZvcmUgPyBwbGVhIGxldCBtZSBrbm93IGlmIGFueW9u ZSBoYXZlIG1vcmUgaW5mby4gb24gdGhpcyAuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF PSJBcmlhbCI+Jm5ic3A7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+VGhh bmsgeW91LDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5QYW5r YWo8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg== --0__=pcU9TRtkwC7FuWpUrtBjlFVXge4SWxMIFi2Hhj3hJPMbHJrfve6iUSQZ-- From owner-sqr-users@list.iex.net Fri Jul 2 05:26:58 1999 Date: Fri, 2 Jul 1999 22:12:43 +1200 From: "Wallach, Jarod" Subject: PeopleSoft Object fax for sending Purchase Orders This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEC473.7797AEE8 Content-Type: text/plain; charset="iso-8859-1" Hi all, we are installing object fax 6 for a client, they are on the following platform Application Financials 7.51 Tools 7.53 Database Oracle 8.04 OpSystem NT4 sp4 the fax server is also on a NT4 sp4 compaq they are using this software to fax there purchase orders in the first instance, this might grow in the future, with the installation we have hit a problem as follows. when printing purchase orders we print a logo in the top left hand corner, this logo is a .bmp file. the purchase order print fine when printer from peoplesoft in both 2 and 3-tier when using the -printer:wp command the problem is this, when you send this through the fax server, the following happens. 1) the logo does not come out correctly, we get a greyed out box where the logo should, I know this usually means that the logo can't be printed. 2) the fonts are for the most part correct however a few of the fields have shifted to the right. 3) the entire document is shifted about 1cm to the right of the page does anyone have any idea as to the cause of the problems, we suspect that this might be related to the print drivers/ font types on the server, but are not sure what to check. we are not sending this in post script mode. any help would be appreciated Jarod Wallach kpmg Enabling Technologies e-mail jwallach@kpmg.co.nz Consultant, KPMG 135 Victoria Street P.O. Box 996 KPMG Wellington Phone +64 4 3828800 x8886 New Zealand Fax +64 4 8021221 Disclaimer: The information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Internet electronic mail message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Internet electronic mail message are subject to the terms and conditions expressed in the governing KPMG client engagement letter ------_=_NextPart_000_01BEC473.7797AEE8 Content-Type: application/octet-stream; name="Jarod Wallach (E-mail).vcf" Content-Disposition: attachment; filename="Jarod Wallach (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Wallach;Jarod FN:Jarod Wallach (E-mail) ORG:KPMG New Zealand;Enabling Technologies TITLE:Consultant TEL;WORK;VOICE:+64 (4) 382 8800 TEL;WORK;FAX:+64 (4) 802 1221 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;KPMG Centre=0D=0A135 Victoria Street=0D=0A(PO Box 996);Wellington;;;New Ze= aland LABEL;WORK;ENCODING=QUOTED-PRINTABLE:KPMG Centre=0D=0A135 Victoria Street=0D=0A(PO Box 996)=0D=0AWellington=0D= =0ANew Zealand EMAIL;PREF;INTERNET:jwallach@kpmg.co.nz REV:19990505T035936Z END:VCARD ------_=_NextPart_000_01BEC473.7797AEE8-- From owner-sqr-users@list.iex.net Fri Jul 2 07:49:05 1999 Date: Fri, 2 Jul 1999 08:34:19 -0400 From: Sherry Jin Subject: Re: Print last page Kris, I believe this is a problem generated within peoplesoft. SQRIBE doesn't recommend attaching printer name after -f (The recommendation is to attach file directory/file after -f). In Peoplesoft, When printer is specified as the output, peoplesoft generates -fLPT2 into the parameter list. Last-Page tries to generate a buffer file to be able to compute last page. Mostly likely, it considers LPT2 as the directory file and attempts to open it as a file. I left a voice mail for peoplesoft regarding this case. Sherry At 09:58 AM 7/1/99 -0700, Kris Narravula wrote: >Robbi, > >I am not trying to create multiple reports and I am also not trying to do >any manipulation of Page Numbers, etc. My question is very simple, I am >getting the error while I am trying to run the report to the printer via >PeopleSoft with SQR's LAST-PAGE command in the report. It works fine when I >run it to the file from the same PeopleSoft Menu. > >The error I am getting is >(SQR 6002) Cannot open the printer file: \\cairo\infosrvs.spf >(2): No such file or directory > >It is not addressed yet. > >Thanks in advance. >Kris > >----- Original Message ----- >From: Wendel, Robbi >Sent: Thursday, July 01, 1999 4:59 AM >Subject: Re: Print last page > > >I apologize if this is something that you have already addressed or answered >previously, but have you considered trying to use NEW-REPORT instead? It >resets the internal page counter and permits multiple reports from same SQR. >I didn't backtrack to look at all information regarding this posting to >date, so you may have already addressed this or ruled this out. > >Have a great day, >Robbi > >-----Original Message----- >From: Kris Narravula [mailto:kris_narravula@HOTMAIL.COM] >Sent: Wednesday, June 30, 1999 3:57 PM >To: Multiple recipients of list SQR-USERS >Subject: Re: Print last page > > >Hi John, Sherry and Every Body, > >I got the same problem and wanted to post it. At the same time I saw the >request on the list and looking for the outcome. > >I am getting the following error when I use LAST-PAGE command to print the >last page number of the report on every page header as 'page 1 of 99' and >run it to a printer from PeopleSoft. It works fine when I run the report to >a file from the same PeopleSoft. > >(SQR 6002) Cannot open the printer file: \\cairo\infosrvs.spf >(2): No such file or directory > >When I remove the LAST-PAGE command and run the report it works fine with >out any error to the file as well as to the printer from PeopleSoft. > >We are on >Oracle 7.3.4.3.1 and is on HPUX 10.20 & >WinNT 4.0 File Server, >SQR 4.3.2 >PeopleSoft HRMS 7.50.00.000 >PeopleTools 7.54.10 > >I am sorry, I may be giving a bit of inconvenience to the only SQR users. I >am posing this here as similar issue is in discussion. > > >Any body has any clues. > > >Thanks in advance > >Kris > >----- Original Message ----- >From: Sherry Jin >Sent: Wednesday, June 30, 1999 12:55 PM >Subject: Re: Print last page > > >John, > >Thanks for the response. > >The problem is resolved if I add -printer:WP into the SQR flag in config >manager and specify file as the output destination. > >What happens is that whenever printer (Say LPT2) is selected as the output, >peoplesoft generates -flpt2 into the process parameter. I believe >"last-page" tries to generate a temp buffer file and considers lpt2 as the >output directory/file. > >Sherry > >At 03:02 PM 6/30/99 -0400, John Milardovic wrote: >>Do you mean 'print-direct'? or -printer:WP? or are you piping to the >printer >>in UNIX? >> >>If print-direct the problem might be that print-direct sends output >directly >>to the printer (i.e.. bypassing the SQR buffer) and so SQR can't calculate >>the number of pages in the report. >> >>John Milardovic >> >>> -----Original Message----- >>> From: Sherry Jin [SMTP:sjin@WINSTAR.COM] >>> Sent: Wednesday, June 30, 1999 1:54 PM >>> To: Multiple recipients of list SQR-USERS >>> Subject: Print last page >>> >>> I am trying to use last-page to print out the total numbers of pages on >>> each page. It works when I use file as the output destination, but >>> receives >>> error message 'Error reading the printer file (22) Invalid argument' when >>> printer is used as the output destination. >>> >>> This is what I added to the code: >>> >>> page-number (1,1) 'Page ' >>> last-page () ' Of ' >>> >>> Adding command last-page causes the error when output is printer. >>> Has anyone been able to invoke last-page and send the output directly to >>> printer? >>> >>> Thanks for any help, >>> Sherry >> >> > > From owner-sqr-users@list.iex.net Fri Jul 2 08:50:19 1999 Date: Fri, 2 Jul 1999 09:37:21 -0400 From: "White, Denise" Subject: Upward Compatibility of SQR Versions I'm hoping someone can save us some time in our upgrade testing by either assuring me of upward compatibility between versions 3 and 4, or pointing me towards potential trouble spots. We currently are running SQR 3.0.18.1.1. We are an Oracle shop, and have two systems that use SQR - PeopleSoft HRMS, and a non-PeopleSoft ERP system (Point.Man). Our ERP system is so heavily customized that a decision has been made to never upgrade it (I'd like to state that I support HRMS and not ERP!). We need to upgrade PeopleSoft to Tools 7.05.10 and HRMS 7.02. This involves an upgrade to SQR 4.3.2. Our DBA strongly feels that he wants only one version of SQR running for both systems. He plans to do some testing of the ERP SQRs, but he assumes that any SQR written in version 2 or 3 will run successfully in version 4. I have heard at a PeopleSoft User Group meeting that it is extremely important to thoroughly test every SQR program, which leads me to believe there may be some incompatibilities. Can anyone shed some light on this issue? One thing I have heard is that in SQR 4, you cannot do "alter session set nls_date_format = 'DD-MON-YYYY';". Unfortunately, I have just recently modified most of my SQRs to use this, after having found that my date math was not working correctly and was not including century in the calculations (another interesting decision had been made here to leave the Oracle default at DD-MON-YY and just program around it for Y2K compliance)! This had seemed by far the easiest solution - how do I do it in SQR 4? Thanks in advance! Denise White Sr IT Application Developer Textron Systems From owner-sqr-users@list.iex.net Fri Jul 2 10:39:33 1999 Date: Fri, 2 Jul 1999 09:58:52 -0400 From: Sam Spritzer Subject: Re: Upward Compatibility of SQR Versions Denise... I don't have the complete URL but if you head over to www.ontko.com you'll find a chart that shows the various commands over the all the versions of SQR. Hope this helps, Sam <<< "White, Denise" 7/ 2 9:37a >>> I'm hoping someone can save us some time in our upgrade testing by either assuring me of upward compatibility between versions 3 and 4, or pointing me towards potential trouble spots. We currently are running SQR 3.0.18.1.1. We are an Oracle shop, and have two systems that use SQR - PeopleSoft HRMS, and a non-PeopleSoft ERP system (Point.Man). Our ERP system is so heavily customized that a decision has been made to never upgrade it (I'd like to state that I support HRMS and not ERP!). We need to upgrade PeopleSoft to Tools 7.05.10 and HRMS 7.02. This involves an upgrade to SQR 4.3.2. Our DBA strongly feels that he wants only one version of SQR running for both systems. He plans to do some testing of the ERP SQRs, but he assumes that any SQR written in version 2 or 3 will run successfully in version 4. I have heard at a PeopleSoft User Group meeting that it is extremely important to thoroughly test every SQR program, which leads me to believe there may be some incompatibilities. Can anyone shed some light on this issue? One thing I have heard is that in SQR 4, you cannot do "alter session set nls_date_format = 'DD-MON-YYYY';". Unfortunately, I have just recently modified most of my SQRs to use this, after having found that my date math was not working correctly and was not including century in the calculations (another interesting decision had been made here to leave the Oracle default at DD-MON-YY and just program around it for Y2K compliance)! This had seemed by far the easiest solution - how do I do it in SQR 4? Thanks in advance! Denise White Sr IT Application Developer Textron Systems From owner-sqr-users@list.iex.net Fri Jul 2 09:47:19 1999 Date: Fri, 2 Jul 1999 09:35:31 -0500 From: Nathan Stratton Treadway Subject: Re: Print last page On Wed, Jun 30, 1999 at 03:55:58PM -0400, Sherry Jin wrote: > The problem is resolved if I add -printer:WP into the SQR flag in config > manager and specify file as the output destination. > > What happens is that whenever printer (Say LPT2) is selected as the output, > peoplesoft generates -flpt2 into the process parameter. I believe > "last-page" tries to generate a temp buffer file and considers lpt2 as the > output directory/file. Yes, you are correct: "last-pages causes SQR to generate an .SPF file, a process which fails if you've specified -flpt2 (because lpt2.spf is an invalid file). The -printer:wp is probably your best workaround, though it can take a bit of work to set up PeopleSoft to handle it. Hopefully, later versions of PeopleSoft will have "native" support, rather than trying to use "-flpt2". (Also, -printer:wp doesn't work under Windows 95 with most versions of SQRW 3.x, which is a problem for sites who haven't upgraded yet.) I wrote a rather lengthy document that explains this problem in more detail (including a list of "SPF File Triggers"). See http://www.sqrug.com/ftp/docs/sqr-windows-printing-howto.html Nathan ---------------------------------------------------------------------------- Nathan Stratton Treadway | Ray Ontko & Co. | Software consulting services nathant@ontko.com | Richmond, IN | http://www.ontko.com/ From owner-sqr-users@list.iex.net Fri Jul 2 10:51:31 1999 Date: Fri, 2 Jul 1999 08:39:20 -0700 From: Pankaj Bedekar Subject: Re: Print last page This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BEC4A1.0D7E7E48 Content-Type: text/plain; charset="iso-8859-1" Kris Sherry is right. when you use LAST-PAGE SQR will put all the output in buffer cause it need to compute total page count before printing. SQR tries to save this buffer file (same name as output destinationin directory where SQRs are resided and if that directory (\\cairo\) does not have permission for users to write the SQR will raise error saying cannot save the file or whatever. if u make that directory allowed to write no error will come but u end up users tampering that files ..... all the best Pankaj Bedekar -----Original Message----- From: Sherry Jin [mailto:sjin@WINSTAR.COM] Sent: Friday, July 02, 1999 5:34 AM To: Multiple recipients of list SQR-USERS Subject: Re: Print last page Kris, I believe this is a problem generated within peoplesoft. SQRIBE doesn't recommend attaching printer name after -f (The recommendation is to attach file directory/file after -f). In Peoplesoft, When printer is specified as the output, peoplesoft generates -fLPT2 into the parameter list. Last-Page tries to generate a buffer file to be able to compute last page. Mostly likely, it considers LPT2 as the directory file and attempts to open it as a file. I left a voice mail for peoplesoft regarding this case. Sherry At 09:58 AM 7/1/99 -0700, Kris Narravula wrote: >Robbi, > >I am not trying to create multiple reports and I am also not trying to do >any manipulation of Page Numbers, etc. My question is very simple, I am >getting the error while I am trying to run the report to the printer via >PeopleSoft with SQR's LAST-PAGE command in the report. It works fine when I >run it to the file from the same PeopleSoft Menu. > >The error I am getting is >(SQR 6002) Cannot open the printer file: \\cairo\infosrvs.spf >(2): No such file or directory > >It is not addressed yet. > >Thanks in advance. >Kris > >----- Original Message ----- >From: Wendel, Robbi >Sent: Thursday, July 01, 1999 4:59 AM >Subject: Re: Print last page > > >I apologize if this is something that you have already addressed or answered >previously, but have you considered trying to use NEW-REPORT instead? It >resets the internal page counter and permits multiple reports from same SQR. >I didn't backtrack to look at all information regarding this posting to >date, so you may have already addressed this or ruled this out. > >Have a great day, >Robbi > >-----Original Message----- >From: Kris Narravula [mailto:kris_narravula@HOTMAIL.COM] >Sent: Wednesday, June 30, 1999 3:57 PM >To: Multiple recipients of list SQR-USERS >Subject: Re: Print last page > > >Hi John, Sherry and Every Body, > >I got the same problem and wanted to post it. At the same time I saw the >request on the list and looking for the outcome. > >I am getting the following error when I use LAST-PAGE command to print the >last page number of the report on every page header as 'page 1 of 99' and >run it to a printer from PeopleSoft. It works fine when I run the report to >a file from the same PeopleSoft. > >(SQR 6002) Cannot open the printer file: \\cairo\infosrvs.spf >(2): No such file or directory > >When I remove the LAST-PAGE command and run the report it works fine with >out any error to the file as well as to the printer from PeopleSoft. > >We are on >Oracle 7.3.4.3.1 and is on HPUX 10.20 & >WinNT 4.0 File Server, >SQR 4.3.2 >PeopleSoft HRMS 7.50.00.000 >PeopleTools 7.54.10 > >I am sorry, I may be giving a bit of inconvenience to the only SQR users. I >am posing this here as similar issue is in discussion. > > >Any body has any clues. > > >Thanks in advance > >Kris > >----- Original Message ----- >From: Sherry Jin >Sent: Wednesday, June 30, 1999 12:55 PM >Subject: Re: Print last page > > >John, > >Thanks for the response. > >The problem is resolved if I add -printer:WP into the SQR flag in config >manager and specify file as the output destination. > >What happens is that whenever printer (Say LPT2) is selected as the output, >peoplesoft generates -flpt2 into the process parameter. I believe >"last-page" tries to generate a temp buffer file and considers lpt2 as the >output directory/file. > >Sherry > >At 03:02 PM 6/30/99 -0400, John Milardovic wrote: >>Do you mean 'print-direct'? or -printer:WP? or are you piping to the >printer >>in UNIX? >> >>If print-direct the problem might be that print-direct sends output >directly >>to the printer (i.e.. bypassing the SQR buffer) and so SQR can't calculate >>the number of pages in the report. >> >>John Milardovic >> >>> -----Original Message----- >>> From: Sherry Jin [SMTP:sjin@WINSTAR.COM] >>> Sent: Wednesday, June 30, 1999 1:54 PM >>> To: Multiple recipients of list SQR-USERS >>> Subject: Print last page >>> >>> I am trying to use last-page to print out the total numbers of pages on >>> each page. It works when I use file as the output destination, but >>> receives >>> error message 'Error reading the printer file (22) Invalid argument' when >>> printer is used as the output destination. >>> >>> This is what I added to the code: >>> >>> page-number (1,1) 'Page ' >>> last-page () ' Of ' >>> >>> Adding command last-page causes the error when output is printer. >>> Has anyone been able to invoke last-page and send the output directly to >>> printer? >>> >>> Thanks for any help, >>> Sherry >> >> > > ------_=_NextPart_001_01BEC4A1.0D7E7E48 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Print last page

Kris

Sherry is right. when you use LAST-PAGE SQR will put = all the output in buffer cause it need to compute total page count = before printing. SQR tries to save this buffer file (same name as = output destinationin directory where SQRs are resided and if that = directory (\\cairo\) does not have permission for users to write the = SQR will raise error saying cannot save the file or whatever. if u make = that directory allowed to write no error will come but u end up users = tampering that files .....

all the best

Pankaj Bedekar

-----Original Message-----
From: Sherry Jin [mailto:sjin@WINSTAR.COM]
Sent: Friday, July 02, 1999 5:34 AM
To: Multiple recipients of list SQR-USERS
Subject: Re: Print last page


Kris,

I believe this is a problem generated within = peoplesoft. SQRIBE doesn't
recommend attaching printer name after -f (The = recommendation is to attach
file directory/file after -f). In Peoplesoft,  = When printer is specified as
the output, peoplesoft generates -fLPT2 into the = parameter list. Last-Page
tries to generate a buffer file to be able to = compute last page. Mostly
likely, it considers LPT2 as the directory file and = attempts to open it as
a file.

I left a voice mail for peoplesoft regarding this = case.

Sherry
At 09:58 AM 7/1/99 -0700, Kris Narravula = wrote:
>Robbi,
>
>I am not trying to create multiple reports and I = am also not trying to do
>any manipulation of Page Numbers, etc. My = question is very simple, I am
>getting the error while I am trying to run the = report to the printer via
>PeopleSoft with SQR's LAST-PAGE command in the = report. It works fine when I
>run it to the file from the same PeopleSoft = Menu.
>
>The error I am getting is
>(SQR 6002) Cannot open the printer file: = \\cairo\infosrvs.spf
>(2): No such file or directory
>
>It is not addressed yet.
>
>Thanks in advance.
>Kris
>
>----- Original Message -----
>From: Wendel, Robbi = <rwendel@NESPOWER.COM>
>Sent: Thursday, July 01, 1999 4:59 AM
>Subject: Re: Print last page
>
>
>I apologize if this is something that you have = already addressed or answered
>previously, but have you considered trying to = use NEW-REPORT instead? It
>resets the internal page counter and permits = multiple reports from same SQR.
>I didn't backtrack to look at all information = regarding this posting to
>date, so you may have already addressed this or = ruled this out.
>
>Have a great day,
>Robbi
>
>-----Original Message-----
>From: Kris Narravula [mailto:kris_narravula@HOTMAIL= .COM]
>Sent: Wednesday, June 30, 1999 3:57 PM
>To: Multiple recipients of list SQR-USERS
>Subject: Re: Print last page
>
>
>Hi  John, Sherry and Every Body,
>
>I got the same problem and wanted to post it. At = the same time I saw the
>request on the list and looking for the = outcome.
>
>I am getting the following error when I use = LAST-PAGE command to print the
>last page number of the report on every page = header as 'page 1 of  99' and
>run it to a printer from PeopleSoft. It works = fine when I run the report to
>a file from the same PeopleSoft.
>
>(SQR 6002) Cannot open the printer file: = \\cairo\infosrvs.spf
>(2): No such file or directory
>
>When I remove the LAST-PAGE command and run the = report it works fine with
>out any error to  the file as well as to = the printer from PeopleSoft.
>
>We are on
>Oracle 7.3.4.3.1 and is on HPUX 10.20 = &
>WinNT 4.0 File Server,
>SQR 4.3.2
>PeopleSoft HRMS 7.50.00.000
>PeopleTools 7.54.10
>
>I am sorry, I may be giving a bit of = inconvenience to the only SQR users. I
>am posing this here as similar issue is in = discussion.
>
>
>Any body has any clues.
>
>
>Thanks in advance
>
>Kris
>
>----- Original Message -----
>From: Sherry Jin <sjin@WINSTAR.COM>
>Sent: Wednesday, June 30, 1999 12:55 PM
>Subject: Re: Print last page
>
>
>John,
>
>Thanks for the response.
>
>The problem is resolved if I add -printer:WP = into the SQR flag in config
>manager and specify file as the output = destination.
>
>What happens is that whenever printer (Say LPT2) = is selected as the output,
>peoplesoft generates -flpt2 into the process = parameter. I believe
>"last-page" tries to generate a temp = buffer file and considers lpt2 as the
>output directory/file.
>
>Sherry
>
>At 03:02 PM 6/30/99 -0400, John Milardovic = wrote:
>>Do you mean 'print-direct'? or -printer:WP? = or are you piping to the
>printer
>>in UNIX?
>>
>>If print-direct the problem might be that = print-direct sends output
>directly
>>to the printer (i.e.. bypassing the SQR = buffer) and so SQR can't calculate
>>the number of pages in the report.
>>
>>John Milardovic
>>
>>> -----Original Message-----
>>> From: Sherry Jin = [SMTP:sjin@WINSTAR.COM]
>>> Sent: Wednesday, June 30, 1999 1:54 = PM
>>> To:   Multiple recipients of = list SQR-USERS
>>> Subject:      = Print last page
>>>
>>> I am trying to use last-page to print = out the total numbers of pages on
>>> each page. It works when I use file as = the output destination, but
>>> receives
>>> error message 'Error reading the = printer file (22) Invalid argument' when
>>> printer is used as the output = destination.
>>>
>>> This is what I added to the = code:
>>>
>>> page-number (1,1) 'Page '
>>> last-page   = ()    ' Of '
>>>
>>> Adding command last-page causes the = error when output is printer.
>>> Has anyone been able to invoke = last-page and send the output directly to
>>> printer?
>>>
>>> Thanks for any help,
>>> Sherry
>>
>>
>
>

------_=_NextPart_001_01BEC4A1.0D7E7E48-- From owner-sqr-users@list.iex.net Fri Jul 2 12:53:31 1999 Date: Fri, 2 Jul 1999 12:41:10 -0500 From: Nathan Stratton Treadway Subject: Re: Upward Compatibility of SQR Versions On Fri, Jul 02, 1999 at 09:37:21AM -0400, White, Denise wrote: > one version of SQR running for both systems. He plans to do some testing of > the ERP SQRs, but he assumes that any SQR written in version 2 or 3 will run > successfully in version 4. I have heard at a PeopleSoft User Group meeting > that it is extremely important to thoroughly test every SQR program, which > leads me to believe there may be some incompatibilities. Can anyone shed > some light on this issue? Yes, there are some incompatibilities, and you should plan to spend a little time making the switch. Most of the changes are very simple, and involve compile-time error messages. Thus, you can simply set up a batch job to do an "sqr -rs" on all of your source programs and look for the programs that don't compile. For example, if you have a move $string_var to #num_var 9,999 command (that is, an edit mask on a move TO a #num_var), the bogus edit mask will now cause a compile-time error. You can simple delete the edit mask and recompile the program. If you are doing a lot of date manipulations, moving those to SQR 4 is a little harder because sometimes the problems don't show up until run time. It's well worth upgrading to use SQR v4's new date features, but if you don't do thorough pre-testing you may stumble across problems as your users run certain programs for the first time under SQR 4. In very rare situations you may run into trouble with the new, more precise numerice variables in SQR 4 (if your program somehow relied on rounding errors, for example). You may need to look at DEFAULT-NUMERIC in SQR.INI. > One thing I have heard is that in SQR 4, you cannot do "alter session set > nls_date_format = 'DD-MON-YYYY';". Unfortunately, I have just recently > modified most of my SQRs to use this, after having found that my date math > was not working correctly and was not including century in the calculations > (another interesting decision had been made here to leave the Oracle default > at DD-MON-YY and just program around it for Y2K compliance)! This had > seemed by far the easiest solution - how do I do it in SQR 4? You can still use nls_date_format; it's just that SQR 4 now does its own conversions from date columns, ignoring this setting when you directly select a date column into an SQR &variable. (Thenls_date_format would still be used if you did a begin-select .... from XXXX where to_char(DATE_COLUMN) like '%-1997' end-select Note that I'd never recommend this particular where clause; the point is that nls_date_format might still be needed in some situations.) The answer to your specific question is that you want to look at the SQR.INI setting SQR_DB_DATE_FORMAT. Nathan ---------------------------------------------------------------------------- Nathan Stratton Treadway | Ray Ontko & Co. | Software consulting services nathant@ontko.com | Richmond, IN | http://www.ontko.com/ From owner-sqr-users@list.iex.net Fri Jul 2 14:20:52 1999 Date: Fri, 2 Jul 1999 12:03:33 -0700 From: Kris Narravula Subject: Re: Print last page This is a multi-part message in MIME format. ------=_NextPart_000_0070_01BEC482.E860E790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Print last pageThanks for everybody responded. I am opening a case = with PeopleSoft to rectify the problem. It seems it is a bug in = PeopleSoft. They might have over looked it. Thanks again Kris ------=_NextPart_000_0070_01BEC482.E860E790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Print last page
Thanks for everybody responded. I am = opening a case=20 with PeopleSoft to rectify the problem. It seems it is a bug in = PeopleSoft. They=20 might have over looked it.
 
Thanks again
 
Kris
 
 

 

------=_NextPart_000_0070_01BEC482.E860E790-- From owner-sqr-users@list.iex.net Sat Jul 3 11:01:18 1999 Date: Sat, 3 Jul 1999 21:22:21 +0530 From: Shankar Subject: Info Needed... Hi all, I am glad to join you all. Can anybody explain me more about the following in SQR Report (since I hv just using SQR Reports) : print &sYearInstal () ON-BREAK PRINT=NEVER AFTER=YEAR_BREAK LEVEL=1 SAVE=$sLastYearInstal BEFORE=PRINT_TITLE print &sMinorCause () ON-BREAK PRINT=NEVER AFTER=MINOR_BREAK LEVEL=2 SAVE=$sLastMnCause How the break is fired , about the Level ...etc Thanks in Advance, Shankar Swamy. From owner-sqr-users@list.iex.net Wed Jul 7 01:43:16 1999 Date: Mon, 5 Jul 1999 08:34:58 +0100 From: Franck Masson Subject: Re: HTML Table of Contents examples I will recommand you to use visualsqribe or to upgrade your visualsqribe. It is a feature that it does by just clicking on the mouse. franck, !-------------------------------------------------------------------------------- ! Generated on Mon Jul 05 08:32:49 1999 by VisualSQRIBE 4.4.0.17 ! ! Filename: C:\sqribe\VisualSQRIBE\PROGRAM\sans.sqr ! Format : Tabular ! Username: S !-------------------------------------------------------------------------------- Begin-Setup Declare-Layout Default Orientation = Portrait Paper-Size = (Letter) Top-Margin = 0.50 Bottom-Margin = 0.50 Left-Margin = 0.50 Right-Margin = 0.50 Line-Height = 1 Char-Width = 1 End-Declare Declare-TOC Default Entry = VS_TOC_Proc End-Declare End-Setup Begin-Heading 22 For-Tocs=(default) Graphic (21,1,540) Horz-Line 20 Alter-Printer Font=4 Point-Size=16 Print 'Table of Contents' (15,415,17) Print-Direct printer=html '%%TOC-Title Table of Contents' Alter-Printer Font=5 Point-Size=10 End-Heading Begin-Procedure VS_TOC_Proc Alter-Printer Font=4 Point-Size=10 Let #indent-size = 24 Let #indentation = 1 + (#indent-size * (#sqr-toc-level - 1)) Print $sqr-toc-text (12,#indentation) Print #sqr-toc-page (12,523) Next-Listing Skiplines=4 Need=14 End-Procedure Begin-Program Do Main End-Program Begin-Procedure Main Position (1,1) Do CreateCSV_Main Print-Direct printer=html '%%ResetColor' Print-Direct printer=html '%%ResetBorder' Begin-Select Alter-Printer Font=4 Point-Size=10 ENAME (10,1,10) Toc-Entry text=&ename level=1 COMM (10,128) Edit 9999999999999999na SAL (10,288) Edit 99999.99na let $COMM_num = to_char(&COMM) let $COMM_num_tmp = edit(&COMM,'999999999999999999999999999999999999999') let $COMM_num = ltrim($COMM_num_tmp,' ') let $SAL_num = to_char(&SAL) let $SAL_num_tmp = edit(&SAL,'99999.99') let $SAL_num = ltrim($SAL_num_tmp,' ') write 1 from '"' &ENAME '"' ',' $COMM_num ',' $SAL_num Next-Listing SkipLines=2 Need=12 >From EMP End-Select Next-Listing End-Procedure Begin-Procedure CreateCSV_Main Add 1 To #_CSVINDEX_Main Let $_CSVFILE_Main='C:/sqribe/VisualSQRIBE/PROGRAM/html/sans_Main_' || to_char(#_CSVINDEX_Main) || '.csv' Open $_CSVFILE_Main as 1 for-writing record=255:vary write 1 from '"ENAME"' ',' '"COMM"' ',' '"SAL"' End-Procedure Begin-Heading 45 Print-Direct printer=html '%%ResetColor' Print-Direct printer=html '%%ResetBorder' Alter-Printer Font=5 Point-Size=10 Print $current-date (10,1) edit 'MM/DD/YY' Page-Number (10,523) Alter-Printer Font=4 Point-Size=10 Print 'Ename' (33,1,5) Underline Bold Print 'Comm' (33,128,4) Underline Bold Print 'Sal' (33,288,3) Underline Bold End-Heading Tonie Salzano wrote: > > Does anyone have an example of an SQR that creates a > Table of Contents that shows a link on a data item, > e.g. deptid, instead of page? > > We have a check distribution report that we need > to make available to our remote campuses. > > Thanks > Tonie Salzano > Maricopa Community College District From owner-sqr-users@list.iex.net Wed Jul 7 18:06:00 1999 Date: Tue, 6 Jul 1999 01:00:15 +0100 From: Franck Masson Subject: Re: processing a .dbf file have you try to use SQR with ODBC driver ? It can be a solution if you have ODBC driver for foxpro. Franck, S+A Sills wrote: > > take a look at the stuff in > > http://www.egroups.com/docvault/psusers/ > > folder named > > sqr to write dbf file for excel , access > > this will ident how to write a dbf file. it also has a descr of a dbf > version VI file format. > > this amy give some hints on how to read. you will be able to address the > field descriptor array and the start of data. From owner-sqr-users@list.iex.net Tue Jul 6 09:41:28 1999 Date: Tue, 6 Jul 1999 10:23:49 -0400 From: "Dray, Adam" Subject: Re: Info Needed... [Shankar Swamy asks how breaks are processed in SQR...] The SQR Language Reference (version 4), page 219, in the section for the Print command includes these details on the On-Break field: "Following is the sequence of events for a query containing ON-BREAK fields: 1. Any BEFORE procedures are processed in ascending LEVEL sequence before the first row of the query is retrieved. 2. When a break occurs in the query, the following happens: a. AFTER procedures are processed in descending sequence from the highest level to the level of the current break field. b. SAVE variables are set with the new value. c. BEFORE procedures are processed in ascending sequence from the current level to the highest level break. d. Any breaks with the same or higher level numbers are cleared so they will not break on the next value. e. If a PROCEDURE has been declared, it is invoked. f. If SKIPLINES was specified, the current line position is advanced. h. The value is printed (unless PRINT=NEVER was specified). 3. After the query finishes (at END-SELECT) any AFTER procedures are processed in descending level sequence." The manual continues with some good examples. I strongly suggest getting access to a copy of the SQR Language Reference and the SQR User's Guide. Many questions that SQR novitiates have can be answered in a few seconds with a quick thumbing of the manuals. Adam Dray From owner-sqr-users@list.iex.net Tue Jul 6 10:13:52 1999 Date: Tue, 6 Jul 1999 11:00:39 -0400 From: "Weaver, Judith R" Subject: Re: Info Needed - SQR on-break logic. I agree with everything you say except item 1. Unless I'm doing something wrong, it appears to me that all BEFORE procedures are processed immediately after the return of the first row of data. I wrote this little sqr to demonstrate for myself when things happen. I've also created a bmp (800x600) and a jpg image of a flow chart if anyone is interested. This particular sqr accesses the PeopleSoft HRMS demo database (version 6.x). If you want to test it out, you'll have to modify it as appropriate. I then uploaded the sqr.log into Excel. (It's a tab delimited file) > ---------- > From: Dray, Adam[SMTP:Adam.Dray@PHH.COM] > Sent: Tuesday, July 06, 1999 10:23 AM > Subject: Re: Info Needed... > > [Shankar Swamy asks how breaks are > processed in SQR...] > > > The SQR Language Reference (version 4), page 219, in the section for > the Print command includes these details on the On-Break field: > > "Following is the sequence of events for a query containing ON-BREAK > fields: > > 1. Any BEFORE procedures are processed in ascending LEVEL sequence > before the first row of the query is retrieved. > > 2. When a break occurs in the query, the following happens: > a. AFTER procedures are processed in descending sequence from the > highest level to the level of the current break field. > b. SAVE variables are set with the new value. > c. BEFORE procedures are processed in ascending sequence from the > current level to the highest level break. > d. Any breaks with the same or higher level numbers are cleared so > they will not break on the next value. > e. If a PROCEDURE has been declared, it is invoked. > f. If SKIPLINES was specified, the current line position is > advanced. > h. The value is printed (unless PRINT=NEVER was specified). > 3. After the query finishes (at END-SELECT) any AFTER procedures are > processed in descending level sequence." > > > The manual continues with some good examples. > > I strongly suggest getting access to a copy of the SQR Language Reference > and the SQR User's Guide. Many questions that SQR novitiates have can > be answered in a few seconds with a quick thumbing of the manuals. > > Adam Dray > From owner-sqr-users@list.iex.net Tue Jul 6 10:26:03 1999 Date: Tue, 6 Jul 1999 11:05:42 -0400 From: "Weaver, Judith R" Subject: Re: Info Needed - SQR on-break logic. This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BEC7C1.0501D7D8 Content-Type: text/plain Ooops! Forgot the attachment. <> > ---------- > From: Weaver, Judith > R[SMTP:WeaverJR@USAFOO.UNITEDSPACEALLIANCE.COM] > Sent: Tuesday, July 06, 1999 11:00 AM > Subject: Re: Info Needed - SQR on-break logic. > > I agree with everything you say except item 1. Unless I'm doing something > wrong, it appears to me that all BEFORE procedures are processed > immediately > after the return of the first row of data. > > I wrote this little sqr to demonstrate for myself when things happen. > I've > also created a bmp (800x600) and a jpg image of a flow chart if anyone is > interested. This particular sqr accesses the PeopleSoft HRMS demo > database > (version 6.x). If you want to test it out, you'll have to modify it as > appropriate. I then uploaded the sqr.log into Excel. (It's a tab > delimited > file) > > > ---------- > > From: Dray, Adam[SMTP:Adam.Dray@PHH.COM] > > Sent: Tuesday, July 06, 1999 10:23 AM > > Subject: Re: Info Needed... > > > > [Shankar Swamy asks how breaks are > > processed in SQR...] > > > > > > The SQR Language Reference (version 4), page 219, in the section for > > the Print command includes these details on the On-Break field: > > > > "Following is the sequence of events for a query containing ON-BREAK > > fields: > > > > 1. Any BEFORE procedures are processed in ascending LEVEL sequence > > before the first row of the query is retrieved. > > > > 2. When a break occurs in the query, the following happens: > > a. AFTER procedures are processed in descending sequence from the > > highest level to the level of the current break field. > > b. SAVE variables are set with the new value. > > c. BEFORE procedures are processed in ascending sequence from the > > current level to the highest level break. > > d. Any breaks with the same or higher level numbers are cleared so > > they will not break on the next value. > > e. If a PROCEDURE has been declared, it is invoked. > > f. If SKIPLINES was specified, the current line position is > > advanced. > > h. The value is printed (unless PRINT=NEVER was specified). > > 3. After the query finishes (at END-SELECT) any AFTER procedures are > > processed in descending level sequence." > > > > > > The manual continues with some good examples. > > > > I strongly suggest getting access to a copy of the SQR Language > Reference > > and the SQR User's Guide. Many questions that SQR novitiates have can > > be answered in a few seconds with a quick thumbing of the manuals. > > > > Adam Dray > > > ------_=_NextPart_000_01BEC7C1.0501D7D8 Content-Type: application/octet-stream; name="sqronbrk1.sqr" Content-Disposition: attachment; filename="sqronbrk1.sqr" !***********************************************************************! ! Program Number: sqronbrk.sqr ! ! Program Name: flow of break logic in sqr ! ! Programmer: Judith R. Weaver ! !-----------------------------------------------------------------------! ! Program Description: This process tests the flow of logic in sqr ! ! using the PeopleSoft HRMS demo database. ! !-----------------------------------------------------------------------! #include 'setenv.sqc' !set environment #include 'setup01.sqc' !set up printer ! portrait begin-program let $tab = chr(9) let $col_hdngs = 'procedure' ||$tab|| '&state' ||$tab|| '&city' ||$tab|| '&zip' ||$tab|| '&name' ||$tab|| '$state' ||$tab|| '$city' ||$tab|| '$zip' ||$tab|| '$name' ||$tab|| '$save_1' ||$tab|| '$save_2' ||$tab|| '$save_3' display $col_hdngs do procedure_1 end-program !--------------------------- begin-procedure procedure_1 begin-select state () on-break level=1 print=never before=before_1 after=after_1 save=$save_1 city () on-break level=2 print=never before=before_2 after=after_2 save=$save_2 zip () on-break level=3 print=never before=before_3 after=after_3 save=$save_3 name do do_stuff from ps_employees where country = 'USA' and city <> ' ' and zip <> ' ' and empl_rcd# = 0 and (state in ('CT','CO') or (state = 'CA' and city like 'A%') ) order by state, city, zip, name end-select end-procedure procedure_1 !--------------------------------- begin-procedure do_stuff move 'do_stuff' to $proc_name move &state to $state move &city to $city move &zip to $zip move &name to $name do display_values end-procedure do_stuff !--------------------------------- begin-procedure before_1 move 'before_1' to $proc_name do display_values end-procedure before_1 !--------------------------------- begin-procedure before_2 move 'before_2' to $proc_name do display_values end-procedure before_2 !--------------------------------- begin-procedure before_3 move 'before_3' to $proc_name do display_values end-procedure before_3 !--------------------------------- begin-procedure after_1 move 'after_1' to $proc_name do display_values end-procedure after_1 !--------------------------------- begin-procedure after_2 move 'after_2' to $proc_name do display_values end-procedure after_2 !--------------------------------- begin-procedure after_3 move 'after_3' to $proc_name do display_values end-procedure after_3 !--------------------------------- begin-procedure display_values string $proc_name &state &city &zip &name $state $city $zip $name $save_1 $save_2 $save_3 by $tab into $log_msg display $log_msg end-procedure display_values ------_=_NextPart_000_01BEC7C1.0501D7D8-- From owner-sqr-users@list.iex.net Tue Jul 6 11:19:59 1999 Date: Tue, 6 Jul 1999 11:04:38 -0500 From: Ray Ontko Subject: Re: Info Needed - SQR on-break logic. Judith, Technically, you are correct. The BEFORE procedures "fire" after the first row of the query is retrieved from the database but before the record is processed as the "current" row in SQR. In other words, all applicable BEFORE procedures are executed before any of the current row logic is applied (explicit SQR commands or implied print statements, for example). Ray > I agree with everything you say except item 1. Unless I'm doing something > wrong, it appears to me that all BEFORE procedures are processed immediately > after the return of the first row of data. > > I wrote this little sqr to demonstrate for myself when things happen. I've > also created a bmp (800x600) and a jpg image of a flow chart if anyone is > interested. This particular sqr accesses the PeopleSoft HRMS demo database > (version 6.x). If you want to test it out, you'll have to modify it as > appropriate. I then uploaded the sqr.log into Excel. (It's a tab delimited > file) > > > ---------- > > From: Dray, Adam[SMTP:Adam.Dray@PHH.COM] > > Sent: Tuesday, July 06, 1999 10:23 AM > > Subject: Re: Info Needed... > > > > [Shankar Swamy asks how breaks are > > processed in SQR...] > > > > > > The SQR Language Reference (version 4), page 219, in the section for > > the Print command includes these details on the On-Break field: > > > > "Following is the sequence of events for a query containing ON-BREAK > > fields: > > > > 1. Any BEFORE procedures are processed in ascending LEVEL sequence > > before the first row of the query is retrieved. > > > > 2. When a break occurs in the query, the following happens: > > a. AFTER procedures are processed in descending sequence from the > > highest level to the level of the current break field. > > b. SAVE variables are set with the new value. > > c. BEFORE procedures are processed in ascending sequence from the > > current level to the highest level break. > > d. Any breaks with the same or higher level numbers are cleared so > > they will not break on the next value. > > e. If a PROCEDURE has been declared, it is invoked. > > f. If SKIPLINES was specified, the current line position is > > advanced. > > h. The value is printed (unless PRINT=NEVER was specified). > > 3. After the query finishes (at END-SELECT) any AFTER procedures are > > processed in descending level sequence." > > > > > > The manual continues with some good examples. > > > > I strongly suggest getting access to a copy of the SQR Language Reference > > and the SQR User's Guide. Many questions that SQR novitiates have can > > be answered in a few seconds with a quick thumbing of the manuals. > > > > Adam Dray > > > ---------------------------------------------------------------------- Ray Ontko | Ray Ontko & Co | "RO&C: data movers and shakers." rayo@ontko.com | Richmond, In | See us at http://www.ontko.com/ From owner-sqr-users@list.iex.net Tue Jul 6 11:51:27 1999 Date: Tue, 6 Jul 1999 11:31:43 -0500 From: Zubin Shroff Subject: Loading Employee data into PS_JOB on AS400 We are trying to load employee data into PS_JOB and other tables using Import Manager. Import Manager errors out when trying to insert into PS_JOB, and we were told to use the JOB_IMPORT view for loading. We are running PS on an AS400, and we apparently cannot update or insert on views on the 400. Just wondering if someone else has run into a similar problem and how they resolved it. Also, any suggestions of alternative methods of loading employee data will be appreciated. Thanks. From owner-sqr-users@list.iex.net Tue Jul 6 13:43:02 1999 Date: Tue, 6 Jul 1999 11:28:39 PDT From: Ben Lawrence Subject: Converting from ASCII to EBCDIC Hi all, I am working on an interface which reports deductions for state retirement. The deduction field must be EBCDIC and it can only be 6 characters in length. I am looking for a way to convert the deduction field from ASCII to EBCDIC within SQR. Has anyone written an SQR that does this conversion? Any help would be greatly appreciated. Thanks, Ben _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From owner-sqr-users@list.iex.net Tue Jul 6 13:52:14 1999 Date: Tue, 6 Jul 1999 11:31:55 -0700 From: Clara Carter Subject: SQR report names Hi, Does anyone know if there is a length limit to the name of the .sqr files. We are on unix. Thanks Clara From owner-sqr-users@list.iex.net Tue Jul 6 13:56:23 1999 Date: Tue, 6 Jul 1999 14:32:13 -0400 From: Rosie ODonnell Subject: Special Characters in a string Hi, Hopefully, this is an easy one. Here is an example: update ps_dept_tble set descr = 'Research & Development' where deptid like '1847%' The ampersand(&) is looked at as a replacement variable. What do I need to surround it with so that the program ignores the ampersand and considers it part of the string? Thanks, Joe Patton Marconi Communications From owner-sqr-users@list.iex.net Tue Jul 6 13:59:47 1999 Date: Tue, 6 Jul 1999 14:48:25 -0400 From: Peter Alan Burton Subject: Re: SQR report names Clara, 1024 characters Peter On 6 Jul 99, at 11:31, Clara Carter wrote: Date sent: Tue, 6 Jul 1999 11:31:55 -0700 Send reply to: SQR-USERS@list.iex.net From: Clara Carter Subject: SQR report names To: Multiple recipients of list SQR-USERS > Hi, > > Does anyone know if there is a length limit to the name of the > .sqr files. We are on unix. > > Thanks > Clara > From owner-sqr-users@list.iex.net Tue Jul 6 14:06:07 1999 Date: Tue, 6 Jul 1999 14:52:52 -0400 From: John Milardovic Subject: Re: Special Characters in a string Hi Rosie. To escape a character just repeat it. && '' ## etc. John Milardovic > -----Original Message----- > From: Rosie ODonnell [SMTP:joe.patton@NA.MARCONICOMMS.COM] > Sent: Tuesday, July 06, 1999 2:32 PM > To: Multiple recipients of list SQR-USERS > Subject: Special Characters in a string > > Hi, > > Hopefully, this is an easy one. Here is an example: > > update ps_dept_tble > set descr = 'Research & Development' > where deptid like '1847%' > > The ampersand(&) is looked at as a replacement variable. What do I need > to > surround it with so that the program ignores the ampersand and considers > it part > of the string? > > Thanks, > > Joe Patton > Marconi Communications From owner-sqr-users@list.iex.net Tue Jul 6 14:09:04 1999 Date: Tue, 6 Jul 1999 13:56:07 CDT From: the dragon Subject: Re: Special Characters in a string Joe, How about taking the easy way out? Replace the & with AND. :-) Special charcaters are a pain in the butt. clark ----Original Message Follows---- Hi, Hopefully, this is an easy one. Here is an example: update ps_dept_tble set descr = 'Research & Development' where deptid like '1847%' The ampersand(&) is looked at as a replacement variable. What do I need to surround it with so that the program ignores the ampersand and considers it part of the string? Thanks, Joe Patton Marconi Communications _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From owner-sqr-users@list.iex.net Tue Jul 6 14:10:26 1999 Date: Tue, 6 Jul 1999 11:57:06 -0700 From: Pankaj Bedekar Subject: Re: Special Characters in a string This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BEC7E1.57B8CB10 Content-Type: text/plain; charset="iso-8859-1" Just use a single quote (') before & sign . pankaj -----Original Message----- From: Rosie ODonnell [mailto:joe.patton@NA.MARCONICOMMS.COM] Sent: Tuesday, July 06, 1999 11:32 AM To: Multiple recipients of list SQR-USERS Subject: Special Characters in a string Hi, Hopefully, this is an easy one. Here is an example: update ps_dept_tble set descr = 'Research & Development' where deptid like '1847%' The ampersand(&) is looked at as a replacement variable. What do I need to surround it with so that the program ignores the ampersand and considers it part of the string? Thanks, Joe Patton Marconi Communications ------_=_NextPart_001_01BEC7E1.57B8CB10 Content-Type: text/html; charset="iso-8859-1" RE: Special Characters in a string

Just use a single quote (') before & sign .

pankaj

-----Original Message-----
From: Rosie ODonnell [mailto:joe.patton@NA.MARCONICOMMS.COM]
Sent: Tuesday, July 06, 1999 11:32 AM
To: Multiple recipients of list SQR-USERS
Subject: Special Characters in a string


Hi,

Hopefully, this is an easy one.  Here is an example:

update ps_dept_tble
set descr = 'Research & Development'
where deptid like '1847%'

The ampersand(&) is looked at as a replacement variable.  What do I need to
surround it with so that the program ignores the ampersand and considers it part
of the string?

Thanks,

Joe Patton
Marconi Communications

------_=_NextPart_001_01BEC7E1.57B8CB10-- From owner-sqr-users@list.iex.net Tue Jul 6 14:09:19 1999 Date: Tue, 6 Jul 1999 14:00:28 -0500 From: "Wendel, Robbi" Subject: Re: Special Characters in a string You might try two single quotes -- ''&'' Robbi -----Original Message----- From: Rosie ODonnell [mailto:joe.patton@NA.MARCONICOMMS.COM] Sent: Tuesday, July 06, 1999 1:32 PM To: Multiple recipients of list SQR-USERS Subject: Special Characters in a string Hi, Hopefully, this is an easy one. Here is an example: update ps_dept_tble set descr = 'Research & Development' where deptid like '1847%' The ampersand(&) is looked at as a replacement variable. What do I need to surround it with so that the program ignores the ampersand and considers it part of the string? Thanks, Joe Patton Marconi Communications From owner-sqr-users@list.iex.net Tue Jul 6 14:20:04 1999 Date: Tue, 6 Jul 1999 14:06:48 -0500 From: Julie Waggoner Subject: Re: Special Characters in a string You can use the Chr() function which returns a character based on the ASCII number you provide. The ampersand is Chr(38). For instance: update ps_dept_tble set descr = 'Research ' || Chr(38) || ' Development' where deptid like '1847%' Julie -----Original Message----- From: Rosie ODonnell [mailto:joe.patton@NA.MARCONICOMMS.COM] Sent: Tuesday, July 06, 1999 1:32 PM To: Multiple recipients of list SQR-USERS Subject: Special Characters in a string Hi, Hopefully, this is an easy one. Here is an example: update ps_dept_tble set descr = 'Research & Development' where deptid like '1847%' The ampersand(&) is looked at as a replacement variable. What do I need to surround it with so that the program ignores the ampersand and considers it part of the string? Thanks, Joe Patton Marconi Communications From owner-sqr-users@list.iex.net Tue Jul 6 14:28:06 1999 Date: Tue, 6 Jul 1999 15:15:36 -0400 From: Arshad Pervez Subject: Re: Special Characters in a string > -----Original Message----- > From: Julie Waggoner [SMTP:WAGGO000@MAIL.GENMILLS.COM] > Sent: Tuesday, July 06, 1999 3:07 PM > To: Multiple recipients of list SQR-USERS > Subject: Re: Special Characters in a string > > You can use the Chr() function which returns a character based on the > ASCII > number you provide. The ampersand is Chr(38). > > For instance: > update ps_dept_tble > set descr = 'Research ' || Chr(38) || ' Development' > where deptid like '1847%' > > Julie > > -----Original Message----- > From: Rosie ODonnell [mailto:joe.patton@NA.MARCONICOMMS.COM] > Sent: Tuesday, July 06, 1999 1:32 PM > To: Multiple recipients of list SQR-USERS > Subject: Special Characters in a string > > > Hi, > > Hopefully, this is an easy one. Here is an example: > > update ps_dept_tble > set descr = 'Research & Development' > where deptid like '1847%' > > The ampersand(&) is looked at as a replacement variable. What do I need > to > surround it with so that the program ignores the ampersand and considers > it > part > of the string? > > Thanks, > > Joe Patton > Marconi Communications From owner-sqr-users@list.iex.net Tue Jul 6 14:29:30 1999 Date: Tue, 6 Jul 1999 15:15:52 -0400 From: John Milardovic Subject: Re: Converting from ASCII to EBCDIC Found this on the net. I'm sure there are hundreds of others. Read Chapter 22 of the Users Guide for instructions. Then again there are probably a dozen easier ways. :-) John Milardovic --------------------------------------------------------------------------- /* ** ASCII <=> EBCDIC conversion functions */ static unsigned char a2e[256] = { 0, 1, 2, 3, 55, 45, 46, 47, 22, 5, 37, 11, 12, 13, 14, 15, 16, 17, 18, 19, 60, 61, 50, 38, 24, 25, 63, 39, 28, 29, 30, 31, 64, 79,127,123, 91,108, 80,125, 77, 93, 92, 78,107, 96, 75, 97, 240,241,242,243,244,245,246,247,248,249,122, 94, 76,126,110,111, 124,193,194,195,196,197,198,199,200,201,209,210,211,212,213,214, 215,216,217,226,227,228,229,230,231,232,233, 74,224, 90, 95,109, 121,129,130,131,132,133,134,135,136,137,145,146,147,148,149,150, 151,152,153,162,163,164,165,166,167,168,169,192,106,208,161, 7, 32, 33, 34, 35, 36, 21, 6, 23, 40, 41, 42, 43, 44, 9, 10, 27, 48, 49, 26, 51, 52, 53, 54, 8, 56, 57, 58, 59, 4, 20, 62,225, 65, 66, 67, 68, 69, 70, 71, 72, 73, 81, 82, 83, 84, 85, 86, 87, 88, 89, 98, 99,100,101,102,103,104,105,112,113,114,115,116,117, 118,119,120,128,138,139,140,141,142,143,144,154,155,156,157,158, 159,160,170,171,172,173,174,175,176,177,178,179,180,181,182,183, 184,185,186,187,188,189,190,191,202,203,204,205,206,207,218,219, 220,221,222,223,234,235,236,237,238,239,250,251,252,253,254,255 }; static unsigned char e2a[256] = { 0, 1, 2, 3,156, 9,134,127,151,141,142, 11, 12, 13, 14, 15, 16, 17, 18, 19,157,133, 8,135, 24, 25,146,143, 28, 29, 30, 31, 128,129,130,131,132, 10, 23, 27,136,137,138,139,140, 5, 6, 7, 144,145, 22,147,148,149,150, 4,152,153,154,155, 20, 21,158, 26, 32,160,161,162,163,164,165,166,167,168, 91, 46, 60, 40, 43, 33, 38,169,170,171,172,173,174,175,176,177, 93, 36, 42, 41, 59, 94, 45, 47,178,179,180,181,182,183,184,185,124, 44, 37, 95, 62, 63, 186,187,188,189,190,191,192,193,194, 96, 58, 35, 64, 39, 61, 34, 195, 97, 98, 99,100,101,102,103,104,105,196,197,198,199,200,201, 202,106,107,108,109,110,111,112,113,114,203,204,205,206,207,208, 209,126,115,116,117,118,119,120,121,122,210,211,212,213,214,215, 216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231, 123, 65, 66, 67, 68, 69, 70, 71, 72, 73,232,233,234,235,236,237, 125, 74, 75, 76, 77, 78, 79, 80, 81, 82,238,239,240,241,242,243, 92,159, 83, 84, 85, 86, 87, 88, 89, 90,244,245,246,247,248,249, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57,250,251,252,253,254,255 }; char ASCIItoEBCDIC(const unsigned char c) { return a2e[c]; } char EBCDICtoASCII(const unsigned char c) { return e2a[c]; } ---------------------------------------------------------------------------- ---------------------------------------- > -----Original Message----- > From: Ben Lawrence [SMTP:ben_lawrence69@HOTMAIL.COM] > Sent: Tuesday, July 06, 1999 2:29 PM > To: Multiple recipients of list SQR-USERS > Subject: Converting from ASCII to EBCDIC > > Hi all, > I am working on an interface which reports deductions for state > retirement. > The deduction field must be EBCDIC and it can only be 6 characters in > length. I am looking for a way to convert the deduction field from ASCII > to > EBCDIC within SQR. Has anyone written an SQR that does this conversion? > Any help would be greatly appreciated. > > Thanks, > Ben > > > _______________________________________________________________ > Get Free Email and Do More On The Web. Visit http://www.msn.com From owner-sqr-users@list.iex.net Tue Jul 6 14:35:18 1999 Date: Tue, 6 Jul 1999 12:20:03 -0700 From: Pankaj Bedekar Subject: Re: Special Characters in a string This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BEC7E4.8C542BF0 Content-Type: text/plain; charset="iso-8859-1" just use 'Research '& Development' use that extra single quote (') before &. Pankaj -----Original Message----- From: Rosie ODonnell [mailto:joe.patton@NA.MARCONICOMMS.COM] Sent: Tuesday, July 06, 1999 11:32 AM To: Multiple recipients of list SQR-USERS Subject: Special Characters in a string Hi, Hopefully, this is an easy one. Here is an example: update ps_dept_tble set descr = 'Research & Development' where deptid like '1847%' The ampersand(&) is looked at as a replacement variable. What do I need to surround it with so that the program ignores the ampersand and considers it part of the string? Thanks, Joe Patton Marconi Communications ------_=_NextPart_001_01BEC7E4.8C542BF0 Content-Type: text/html; charset="iso-8859-1" RE: Special Characters in a string

just use
   'Research '& Development'

use that extra single quote (') before &.

Pankaj


-----Original Message-----
From: Rosie ODonnell [mailto:joe.patton@NA.MARCONICOMMS.COM]
Sent: Tuesday, July 06, 1999 11:32 AM
To: Multiple recipients of list SQR-USERS
Subject: Special Characters in a string


Hi,

Hopefully, this is an easy one.  Here is an example:

update ps_dept_tble
set descr = 'Research & Development'
where deptid like '1847%'

The ampersand(&) is looked at as a replacement variable.  What do I need to
surround it with so that the program ignores the ampersand and considers it part
of the string?

Thanks,

Joe Patton
Marconi Communications

------_=_NextPart_001_01BEC7E4.8C542BF0-- From owner-sqr-users@list.iex.net Tue Jul 6 14:41:38 1999 Date: Tue, 6 Jul 1999 15:29:24 -0400 From: John Milardovic Subject: Re: Special Characters in a string I tried basically the same code and didn't have any problem. begin-sql update tableX set columnY = 'Res & Dev' where columnZ = 100; commit; end-sql My table was updated correctly using Oracle 8 and SQR 4. John Milardovic > -----Original Message----- > From: Rosie ODonnell [SMTP:joe.patton@NA.MARCONICOMMS.COM] > Sent: Tuesday, July 06, 1999 2:32 PM > To: Multiple recipients of list SQR-USERS > Subject: Special Characters in a string > > Hi, > > Hopefully, this is an easy one. Here is an example: > > update ps_dept_tble > set descr = 'Research & Development' > where deptid like '1847%' > > The ampersand(&) is looked at as a replacement variable. What do I need > to > surround it with so that the program ignores the ampersand and considers > it part > of the string? > > Thanks, > > Joe Patton > Marconi Communications From owner-sqr-users@list.iex.net Tue Jul 6 14:44:17 1999 Date: Tue, 6 Jul 1999 12:32:17 -0700 From: Joe Subject: select works in SQL but not in SQR Greetings SQRUG Gurus! Can anybody help me see what is not working here? In SQLPlus, I can use select proc_we_dt, prod_comm_cur from ps_dist_summary where project_id = '10001' and proc_we_dt >= '22-JAN-99' and proc_we_dt < '19-FEB-99' and I get the following data: PROC_WE PROD_COMM_CUR --------- --------------- 22-JAN-99 193.20 29-JAN-99 361.34 05-FEB-99 361.54 12-FEB-99 240.92 22-JAN-99 -9.06 29-JAN-99 -5.06 05-FEB-99 -9.06 12-FEB-99 -9.08 8 rows selected. but in my SQR, I have: begin-select to_char(proc_we_dt,'mm/dd/yy') &proc_we_dt_fm round(sum(prod_comm_cur), 0) &prod_comm_cur from ps_dist_summary where project_id = $project_id and dist_dt > to_date($asof_dt,'mm/dd/yyyy') and to_date($proc_we_dt,'mm/dd/yyyy') >= to_date($proc_we_dt_dtu_limit,'mm/dd/yyyy') and to_date($proc_we_dt,'mm/dd/yyyy') < to_date($asof_dt,'mm/dd/yyyy') group by to_char(proc_we_dt,'mm/dd/yy') order by to_char(proc_we_dt,'mm/dd/yy') end-select And I get no data. I use '10001' for $project_id '22-JAN-99' for to_date($proc_we_dt_dtu_limit,'mm/dd/yyyy') and '19-FEB-99' for to_date($asof_dt,'mm/dd/yyyy') AGGGGHHHH!!!!!!! Maybe my brain is fried from looking at the monitor for so long, but that shoe sales job at the mall is looking better and better! TIA Joe Johnson jejohn1216@surfree.com ~~ JEJ ~~ ;{) -------------------------------------------------------- $14.95 Unlimited Internet Access, http://www.surfree.com From owner-sqr-users@list.iex.net Tue Jul 6 14:48:12 1999 Date: Tue, 6 Jul 1999 19:35:23 GMT From: Dhananjay Nikkam Subject: reading from a flat file Hi guys, I am trying to read from a flat file, which consists of data for the BI_HDR and the BI_LINE tables. That is Header and detail info. So one line of HDR can consist of one or more detail lines. They are linked by a transaction ID. The flat file looks like something below. Can anyone suggest the most efficient way of acheiving this? Rec TransID. Date CustID Cust# counts totalamt type --- ------- ---- ------ ----- ------ -------- A 11788 06/11/99 678 1 AXDDFF 7675 B 11788 50 4000) B 11788 100 3675) line info Rec. type A,is the header info and Rec type B, will be the line info and linked by the TransID. Thanks DJ _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From owner-sqr-users@list.iex.net Tue Jul 6 15:04:24 1999 Date: Tue, 6 Jul 1999 12:54:33 -0700 From: Clara Carter Subject: Re: select works in SQL but not in SQR I think it has to do with your date formats in the to_date functions. You are telling it to expect it in the 'mm/dd/yyyy' format but you are passing it '22-JAN-99'. So then the conversion is wrong. This is what it's reading in: and to_date('22-JAN-99','mm/dd/yyyy') when I think it should be and to_date('22-JAN-99','MM-MON-YY') Just a start.... Clara where project_id = $project_id > and dist_dt > to_date($asof_dt,'mm/dd/yyyy') > and to_date($proc_we_dt,'mm/dd/yyyy') >= >to_date($proc_we_dt_dtu_limit,'mm/dd/yyyy') > and to_date($proc_we_dt,'mm/dd/yyyy') < to_date($asof_dt,'mm/dd/yyyy') At 12:32 PM 7/6/99 -0700, you wrote: >Greetings SQRUG Gurus! > >Can anybody help me see what is not working here? > >In SQLPlus, I can use > > select proc_we_dt, prod_comm_cur > from ps_dist_summary > where project_id = '10001' > and proc_we_dt >= '22-JAN-99' > and proc_we_dt < '19-FEB-99' > >and I get the following data: > > PROC_WE PROD_COMM_CUR > --------- --------------- > 22-JAN-99 193.20 > 29-JAN-99 361.34 > 05-FEB-99 361.54 > 12-FEB-99 240.92 > 22-JAN-99 -9.06 > 29-JAN-99 -5.06 > 05-FEB-99 -9.06 > 12-FEB-99 -9.08 > > 8 rows selected. > >but in my SQR, I have: > > begin-select > to_char(proc_we_dt,'mm/dd/yy') &proc_we_dt_fm > round(sum(prod_comm_cur), 0) &prod_comm_cur > from ps_dist_summary > where project_id = $project_id > and dist_dt > to_date($asof_dt,'mm/dd/yyyy') > and to_date($proc_we_dt,'mm/dd/yyyy') >= >to_date($proc_we_dt_dtu_limit,'mm/dd/yyyy') > and to_date($proc_we_dt,'mm/dd/yyyy') < to_date($asof_dt,'mm/dd/yyyy') > > group by to_char(proc_we_dt,'mm/dd/yy') > > order by to_char(proc_we_dt,'mm/dd/yy') > > end-select > >And I get no data. > >I use '10001' for $project_id > '22-JAN-99' for to_date($proc_we_dt_dtu_limit,'mm/dd/yyyy') > and '19-FEB-99' for to_date($asof_dt,'mm/dd/yyyy') > >AGGGGHHHH!!!!!!! > >Maybe my brain is fried from looking at the monitor for so long, but that >shoe sales job at the mall is looking better and better! > >TIA > >Joe Johnson >jejohn1216@surfree.com > >~~ JEJ ~~ ;{) > >-------------------------------------------------------- >$14.95 Unlimited Internet Access, http://www.surfree.com From owner-sqr-users@list.iex.net Tue Jul 6 16:01:06 1999 Date: Tue, 6 Jul 1999 16:26:56 -0400 From: "Sarabudla, Raji R." Subject: Re: reading from a flat file Hi Dhananjay, You can achieve this by reading the flat file into variables and check the Rec Type, if the Rec Type is A insert into BI_HDR table, else insert into BI_LINE Table. Make sure the Field Lengths,Date Formats etc. Read all the Values into String Variables and Convert them into Numbers later. The following example makes you easy to understand. Example: begin-procedure main let $filename = 'C:\temp\temp.dat' open $filename as 1 for-reading record=100 status=#filestat while 1 read 1 into $RectYPE:2 $TransID:10 $Date:10 $CustID:10 $Cust#:10 $counts:4 $totalamt:12 ! convert necessary string variables into number variables before inserting. let $RecType = rtrim($RecType,'') let #counts = edit($counts,'99') let #totalamt = edit($totalamt,'9999999.99') etc. if $RecType = 'A' --- When even the Rectype A reads, it inserts into Header Table, otherwise, inserts into detail table. insert into BI_HDR(RecType,TransID,TDATe etc.) Values ($RecType,$TransID,#counts,#totalamt etc.) ! make sure the syntax here. else insert into BI_LINE(RecType,TransID,TDATe etc.) Values ($RecType,$TransID,#counts,#totalamt etc.) end-if if #end-file break end-if end-while end-procedure Hope this helps, Raji ---------- From: Dhananjay Nikkam [SMTP:nikkam@hotmail.com] Sent: Tuesday, July 06, 1999 3:35 PM To: Multiple recipients of list SQR-USERS Subject: reading from a flat file Hi guys, I am trying to read from a flat file, which consists of data for the BI_HDR and the BI_LINE tables. That is Header and detail info. So one line of HDR can consist of one or more detail lines. They are linked by a transaction ID. The flat file looks like something below. Can anyone suggest the most efficient way of acheiving this? Rec TransID. Date CustID Cust# counts totalamt type --- ------- ---- ------ ----- ------ -------- A 11788 06/11/99 678 1 AXDDFF 7675 B 11788 50 4000) B 11788 100 3675) line info Rec. type A,is the header info and Rec type B, will be the line info and linked by the TransID. Thanks DJ _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From owner-sqr-users@list.iex.net Tue Jul 6 15:47:20 1999 Date: Tue, 6 Jul 1999 13:27:10 -0700 From: "Lynds,Rick" Subject: Re: select works in SQL but not in SQR Joe, Looking at your code, did you really mean '$proc_we_dt' - if your code fragment is complete, that would be an empty string - hence no data. Rick rlynds@mwd.dst.ca.us -----Original Message----- From: Joe [mailto:jejohn1216@SURFREE.COM] Sent: Tuesday, July 06, 1999 12:32 PM To: Multiple recipients of list SQR-USERS Subject: select works in SQL but not in SQR Greetings SQRUG Gurus! Can anybody help me see what is not working here? In SQLPlus, I can use select proc_we_dt, prod_comm_cur from ps_dist_summary where project_id = '10001' and proc_we_dt >= '22-JAN-99' and proc_we_dt < '19-FEB-99' and I get the following data: PROC_WE PROD_COMM_CUR --------- --------------- 22-JAN-99 193.20 29-JAN-99 361.34 05-FEB-99 361.54 12-FEB-99 240.92 22-JAN-99 -9.06 29-JAN-99 -5.06 05-FEB-99 -9.06 12-FEB-99 -9.08 8 rows selected. but in my SQR, I have: begin-select to_char(proc_we_dt,'mm/dd/yy') &proc_we_dt_fm round(sum(prod_comm_cur), 0) &prod_comm_cur from ps_dist_summary where project_id = $project_id and dist_dt > to_date($asof_dt,'mm/dd/yyyy') and to_date($proc_we_dt,'mm/dd/yyyy') >= to_date($proc_we_dt_dtu_limit,'mm/dd/yyyy') and to_date($proc_we_dt,'mm/dd/yyyy') < to_date($asof_dt,'mm/dd/yyyy') group by to_char(proc_we_dt,'mm/dd/yy') order by to_char(proc_we_dt,'mm/dd/yy') end-select And I get no data. I use '10001' for $project_id '22-JAN-99' for to_date($proc_we_dt_dtu_limit,'mm/dd/yyyy') and '19-FEB-99' for to_date($asof_dt,'mm/dd/yyyy') AGGGGHHHH!!!!!!! Maybe my brain is fried from looking at the monitor for so long, but that shoe sales job at the mall is looking better and better! TIA Joe Johnson jejohn1216@surfree.com ~~ JEJ ~~ ;{) -------------------------------------------------------- $14.95 Unlimited Internet Access, http://www.surfree.com From owner-sqr-users@list.iex.net Tue Jul 6 16:06:30 1999 Date: Tue, 6 Jul 1999 16:50:48 -0400 From: Krisjanis Gale Subject: neat way of parsing delimited list of strings... necessity is the mother invention. working on an SQR that parses values in a table and then generates an SQR that acts on those values (don't ask! it's ugly what i'm doing!) i ran into the problem of not having an easy way to pull strings from a comma-delimited string, one by one. so i decided to "make it so." here's a working SQR ditty that does just what i thought it would. it first counts the number of words in the string ($S), then lists them invidually. perhaps some of you will find this useful. -- begin-program let $S = 'this,is,a,comma,delimited,string' let $S = $S || ',@' let $tmp = $S let $head = '' let #wordcount = 0 while $tmp <> '@' let #pos = instr($tmp,',',1) let $tmp = substr($tmp,#pos+1,length($tmp)-#pos) let #wordcount = #wordcount + 1 end-while display #wordcount let $tmp = $S let $head = '' while $tmp <> '@' let #pos = instr($tmp,',',1) let $head = substr($tmp,1,#pos - 1) display $head let $tmp = substr($tmp,#pos+1,length($S)-#pos) end-while end-program -- (kris)janis p. gale hrsd - federal reserve bank of new york x8163 From owner-sqr-users@list.iex.net Tue Jul 6 16:33:00 1999 Date: Tue, 6 Jul 1999 16:53:35 -0400 From: "Sarabudla, Raji R." Subject: Re: select works in SQL but not in SQR Hi Joe, The Select Syntax in SQR is not correct, you need not format the Database columns in where clause. you can simply use those columns and format String Dates (SQR Date Variables) against the Database Columns in where clause. May be the following Select clause works for you, Begin-procedure main begin-select to_char(proc_we_dt,'mm/dd/yyyy') &proc_we_dt_fm round(prod_comm_cur), 0) &prod_comm_cur from ps_dist_summary where project_id = $project_id and dist_dt > to_date($asof_dt,'mm/dd/yyyy') and proc_we_dt >= to_date($proc_we_dt_dtu_limit,'mm/dd/yyyy') and proc_we_dt < to_date($asof_dt,'mm/dd/yyyy') order by proc_we_dt end-procedure main If you want use the Group by Columns, the syntax has to be changed and the Group columns have to be verified before using any Group columns. Hope this may atleast help. Thanks, Raji ---------- From: Joe [SMTP:jejohn1216@SURFREE.COM] Sent: Tuesday, July 06, 1999 3:32 PM To: Multiple recipients of list SQR-USERS Subject: select works in SQL but not in SQR Greetings SQRUG Gurus! Can anybody help me see what is not working here? In SQLPlus, I can use select proc_we_dt, prod_comm_cur from ps_dist_summary where project_id = '10001' and proc_we_dt >= '22-JAN-99' and proc_we_dt < '19-FEB-99' and I get the following data: PROC_WE PROD_COMM_CUR --------- --------------- 22-JAN-99 193.20 29-JAN-99 361.34 05-FEB-99 361.54 12-FEB-99 240.92 22-JAN-99 -9.06 29-JAN-99 -5.06 05-FEB-99 -9.06 12-FEB-99 -9.08 8 rows selected. but in my SQR, I have: begin-select to_char(proc_we_dt,'mm/dd/yy') &proc_we_dt_fm round(sum(prod_comm_cur), 0) &prod_comm_cur from ps_dist_summary where project_id = $project_id and dist_dt > to_date($asof_dt,'mm/dd/yyyy') and to_date($proc_we_dt,'mm/dd/yyyy') >= to_date($proc_we_dt_dtu_limit,'mm/dd/yyyy') and to_date($proc_we_dt,'mm/dd/yyyy') < to_date($asof_dt,'mm/dd/yyyy') group by to_char(proc_we_dt,'mm/dd/yy') order by to_char(proc_we_dt,'mm/dd/yy') end-select And I get no data. I use '10001' for $project_id '22-JAN-99' for to_date($proc_we_dt_dtu_limit,'mm/dd/yyyy') and '19-FEB-99' for to_date($asof_dt,'mm/dd/yyyy') AGGGGHHHH!!!!!!! Maybe my brain is fried from looking at the monitor for so long, but that shoe sales job at the mall is looking better and better! TIA Joe Johnson jejohn1216@surfree.com ~~ JEJ ~~ ;{) -------------------------------------------------------- $14.95 Unlimited Internet Access, http://www.surfree.com From owner-sqr-users@list.iex.net Tue Jul 6 17:22:18 1999 Date: Tue, 6 Jul 1999 18:09:20 -0400 From: S+A Sills Subject: Re: reading from a flat file you could in a read loop read the entire record into $rec then test the first byte of $rec if = A do parse-into-header-fields do header-stuff else do parse-into-detail-fields do detail-stuff end_if this should work unless I am missing something >Hi guys, > >I am trying to read from a flat file, which consists of data for the BI_HDR >and the BI_LINE tables. That is Header and detail info. So one line of HDR >can consist of one or more detail lines. They are linked by a transaction >ID. The flat file looks like something below. Can anyone suggest the most >efficient way of acheiving this? > >Rec TransID. Date CustID Cust# counts totalamt >type >--- ------- ---- ------ ----- ------ -------- >A 11788 06/11/99 678 1 AXDDFF 7675 > >B 11788 50 4000) >B 11788 100 3675) line info > >Rec. type A,is the header info and Rec type B, will be the line >info and linked by the TransID. > >Thanks >DJ > > > > >_______________________________________________________________ >Get Free Email and Do More On The Web. Visit http://www.msn.com > > From owner-sqr-users@list.iex.net Tue Jul 6 17:23:10 1999 Date: Wed, 7 Jul 1999 08:12:00 +1000 From: Paul Schattling Subject: Sqr Barcodes Hi gang, Using SQR 3.0 for PeopleSoft 6.0 on Oracle & Unix Has anyone had any sucess with the creation and/or is currently using sqr to produce barcodes. We want to print off barcodes for our asset management system but are having major troubles. I was hoping to produce 4 * 7 barcodes on an A4 sheet. I am able to produce a somewhat distorted replica of a barcode but am far from printing them out as I would have liked. Perhaps someone might have an sqr in place that is similiar???? Hoping for help, Paul From owner-sqr-users@list.iex.net Tue Jul 6 17:30:25 1999 Date: Tue, 6 Jul 1999 18:19:11 -0400 From: S+A Sills Subject: Re: Loading Employee data into PS_JOB on AS400 using the application designer save as job_import to myjob_import. answer yes to the peoplecode copy prompt ( I am not sure if there is any pc behind job_import ). change myjob_import from a view to a table and then do a build. import into myjob_import. then use sql to copy to ps_job. ps never done it, can't even spell AS400, but this might work. > We are trying to load employee data into PS_JOB and other tables using > Import Manager. Import Manager errors out when trying to insert into > PS_JOB, and we were told to use the JOB_IMPORT view for loading. We > are running PS on an AS400, and we apparently cannot update or insert > on views on the 400. Just wondering if someone else has run into a > similar problem and how they resolved it. > > Also, any suggestions of alternative methods of loading employee data > will be appreciated. > > Thanks. > > From owner-sqr-users@list.iex.net Tue Jul 6 17:37:11 1999 Date: Tue, 6 Jul 1999 15:24:58 -0700 From: Pankaj Bedekar Subject: Re: Sqr Barcodes This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BEC7FE.651D6B40 Content-Type: text/plain; charset="iso-8859-1" Paul Need to declare printer on your own.... dont use senenv01/02 . sqc declare printer ! Declare printer characteristics type=HPLASERJET ! Types: POSTSCRIPT, HPLASERJET, or LINEPRINTER left-margin=.50 top-margin=.25 font=6 ! Font number font-style=fixed lines-inch=6 ! Lines per inch point-size=6 orientation=portrait ! portrait or landscape following statements prints bar code very well for us ... type I used is "3 of 9".... let $pack_no = edit(#pack_nbr,'000009') print-bar-code (+1,90) type=5 height= 0.4 text=$pack_no pankaj -----Original Message----- From: Paul Schattling [mailto:P.Schattling@MAILBOX.GU.EDU.AU] Sent: Tuesday, July 06, 1999 3:12 PM To: Multiple recipients of list SQR-USERS Subject: Sqr Barcodes Hi gang, Using SQR 3.0 for PeopleSoft 6.0 on Oracle & Unix Has anyone had any sucess with the creation and/or is currently using sqr to produce barcodes. We want to print off barcodes for our asset management system but are having major troubles. I was hoping to produce 4 * 7 barcodes on an A4 sheet. I am able to produce a somewhat distorted replica of a barcode but am far from printing them out as I would have liked. Perhaps someone might have an sqr in place that is similiar???? Hoping for help, Paul ------_=_NextPart_001_01BEC7FE.651D6B40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Sqr Barcodes

Paul

Need to declare printer on your own.... dont use = senenv01/02 . sqc

   declare = printer        ! Declare printer = characteristics
   = type=3DHPLASERJET        ! Types: = POSTSCRIPT, HPLASERJET, or LINEPRINTER
   left-margin=3D.50
   top-margin=3D.25
   = font=3D6          &nbs= p;      ! Font number
   font-style=3Dfixed
   = lines-inch=3D6         &nbs= p; ! Lines per inch
   point-size=3D6
   orientation=3Dportrait   ! = portrait or landscape

following statements prints bar code very well for us = ...
type I used is "3 of 9"....

   let $pack_no =3D = edit(#pack_nbr,'000009')
   print-bar-code (+1,90)
      type=3D5   =
      height=3D 0.4
      = text=3D$pack_no

pankaj


-----Original Message-----
From: Paul Schattling [mailto:P.Schattling@MAILB= OX.GU.EDU.AU]
Sent: Tuesday, July 06, 1999 3:12 PM
To: Multiple recipients of list SQR-USERS
Subject: Sqr Barcodes


Hi gang,

Using SQR 3.0 for PeopleSoft 6.0 on Oracle & = Unix

Has anyone had any sucess with the creation and/or is = currently using sqr
to produce barcodes.
We want to print off barcodes for our asset = management system but are
having major troubles.
I was hoping to produce 4 * 7 barcodes on an A4 = sheet.
I am able to produce a somewhat distorted replica of = a barcode but am far
from printing them out as I would have liked.
Perhaps someone might have an sqr in place that is = similiar????

Hoping for help,
Paul

------_=_NextPart_001_01BEC7FE.651D6B40-- From owner-sqr-users@list.iex.net Tue Jul 6 17:56:03 1999 Date: Tue, 6 Jul 1999 17:40:40 -0500 From: Zubin Shroff Subject: Error adding subrecord to PS_JOB We added a subrecord to the PS_JOB table. The fields from the subrecord were added to the Hire panels. However, when trying to hire an employee, before any of the panels load, the following PeopleCode error occurs: "Invalid parameter 1 for CurrentRowNumber function" - Is there some peoplecode I need to add/remove/modify when adding a subrecord to job? - Do fields from a subrecord need to be on a subpanel? They are currently on the main hire panels, and we were wondering if that had something to do with the error. Any help will be appreciated. Thanks. From owner-sqr-users@list.iex.net Tue Jul 6 17:56:35 1999 Date: Tue, 6 Jul 1999 17:40:40 -0500 From: Zubin Shroff Subject: Missing views when rebuilding PS_JOB We had added a couple of fields to the PS_JOB table through App Designer. When rebuilding the table, I checked the options to recreate all views. There are over 50 different views for the JOB record, and the rebuild process did not seem to recreate any of these views. We had to run a DDL audit on the database and recreate each view. Any ideas/explanations? Thanks. From owner-sqr-users@list.iex.net Tue Jul 6 20:42:48 1999 Date: Tue, 6 Jul 1999 18:32:24 -0700 From: Tonie Salzano Subject: HTML Table of Contents examples Does anyone have an example of an SQR that creates a Table of Contents that shows a link on a data item, e.g. deptid, instead of page? We have a check distribution report that we need to make available to our remote campuses. Thanks Tonie Salzano Maricopa Community College District From owner-sqr-users@list.iex.net Tue Jul 6 21:15:36 1999 Date: Tue, 6 Jul 1999 19:04:23 PDT From: Stephen Ratliff Subject: Re: [Sqr Barcodes] What type of printer are you using? I have found that using the SQR command of print-bar-code does not work for lineprinter, but I have had success with 2 of 5 and Extended Code 39. Does the 3.0 SQR allow for the command print-bar-code? Give an example of your barcode code. I'd like to see what it looks like. Stephen Ratliff Paul Schattling wrote: Hi gang, Using SQR 3.0 for PeopleSoft 6.0 on Oracle & Unix Has anyone had any sucess with the creation and/or is currently using sqr to produce barcodes. We want to print off barcodes for our asset management system but are having major troubles. I was hoping to produce 4 * 7 barcodes on an A4 sheet. I am able to produce a somewhat distorted replica of a barcode but am far from printing them out as I would have liked. Perhaps someone might have an sqr in place that is similiar???? Hoping for help, Paul ____________________________________________________________________ Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com. From owner-sqr-users@list.iex.net Wed Jul 7 05:40:57 1999 Date: Wed, 7 Jul 1999 06:25:21 EDT From: Steffon Johnson Subject: Re: Error adding subrecord to PS_JOB Dear Zubin, you may want to check the fields on the subrecord that you added for any RowInit and/or RowSelect PeopleCode that is not encapsulated by %Panel and/or %PanelGroup. That is, unless your code reads ... ...If %Panel = PANEL.YOURPANEL, etc you might have envoked code that should fire elsewhere. Additioanlly, the error message "Invalid parameter 1 for CurrentRowNumber function" suggests that the function CurrentRowNumber() is not used correctly. Trace the code via App Reviewer. HTH, Steffon From owner-sqr-users@list.iex.net Wed Jul 7 07:18:03 1999 Date: Wed, 7 Jul 1999 07:51:15 -0400 From: Jim Hardesty Subject: Crossposting Just a gentle reminder that this is the SQR mailing list. While PeopleSoft specific SQR questions are appropriate here, PeopleTools questions are not. PeopleSoft questions are more appropriately addressed on the psusers list (http://www.egroups.com/group/psusers/). momentarily usurping the admin role... jim From owner-sqr-users@list.iex.net Wed Jul 7 08:45:20 1999 Date: Wed, 7 Jul 1999 08:57:59 -0400 From: Anthony Leung-New York Subject: Question on CALL SYSTEM Dear all, I have a sqr that is running on a Windows 95 environment. I need to do a CALL SYSTEM to copy files from one directory to another. According to the SQR Reference book the syntax should be as follow: CALL SYSTEM USING 'copy c:\source\*.* c:\target\' #s where #s returns the status of the call. I ran the sqr but the return status is always 2 (which indicates an error) and nothing gets copied over to the target Can someone shed some light in this area. Thanks From owner-sqr-users@list.iex.net Wed Jul 7 08:57:10 1999 Date: Wed, 7 Jul 1999 09:35:16 -0400 From: "Fehl, Douglas" Subject: Re: Question on CALL SYSTEM I believe the problem may be with your DOS command. For the target directory, either leave the last backslash off: c:\target or add the wildcards: c:\target\*.* > ---------- > From: Anthony Leung-New York[SMTP:ALeung@RUSSREYN.COM] > Sent: Wednesday, July 07, 1999 8:57 AM > To: Multiple recipients of list SQR-USERS > Subject: Question on CALL SYSTEM > > Dear all, > > I have a sqr that is running on a Windows 95 environment. I need to do a > CALL SYSTEM to copy files from one directory to another. According to the > SQR Reference book the syntax should be as follow: > > CALL SYSTEM USING 'copy c:\source\*.* c:\target\' #s > > > where #s returns the status of the call. > > I ran the sqr but the return status is always 2 (which indicates an error) > and nothing gets copied over to the target > > Can someone shed some light in this area. > > Thanks > From owner-sqr-users@list.iex.net Wed Jul 7 09:00:31 1999 Date: Wed, 7 Jul 1999 09:37:53 -0400 From: Bill Milano Subject: Re: Question on CALL SYSTEM I ran into the same exact problem a few weeks ago. One of the guys in our group (Moorthy Saga) called SQR and found out what the story is. Executing a system command under Windows is a lot more difficult than I thought. The documentation makes it sound really simple, but unless you are running on top of UNIX, it's a pain in the ass. The code should be relatively self explanatory. The only tricky thing is that if you do this in a local procedure, you'll need to test the variable "$_sqr-platform" instead of "$sqr-platform". Here is an multi-platform example for doing a sort. !-------------------------------------------------------------------------- ! Sort the temporary file created earlier using Operating System's SORT !-------------------------------------------------------------------------- move 99 to #cmd_status evaluate $sqr-platform when = 'WINDOWS' call system using 'SORT tempvms1.txt tempvms2.txt' #cmd_status WAIT break when = 'WINDOWS-NT' if instr(lower(getenv('COMSPEC')), 'command.com', 1) !------------------------------------------------------------- ! Windows 95 !------------------------------------------------------------- let $cmd = getenv('COMSPEC') || ' /c SORT tempvms1.txt > tempvms2.txt' else !------------------------------------------------------------- ! Windows NT !------------------------------------------------------------- let $cmd = 'cmd /c @start /min /wait cmd /c "SORT < tempvms1.txt > tempvms2.txt"' end-if call system using $cmd #cmd_status WAIT break when = 'UNIX' call system using 'SORT tempvms1.txt > tempvms2.txt' #cmd_status WAIT break end-evaluate if #cmd_status != 0 let $error_string = 'Platform: ' || $sqr-platform || ' - Sort returned error code: ' || to_char(#cmd_status) do issue_error($error_string, 8, 'Y') end-if Please respond to SQR-USERS@list.iex.net To: Multiple recipients of list SQR-USERS cc: (bcc: Bill Milano/AMS/AMSINC) Subject: Question on CALL SYSTEM Dear all, I have a sqr that is running on a Windows 95 environment. I need to do a CALL SYSTEM to copy files from one directory to another. According to the SQR Reference book the syntax should be as follow: CALL SYSTEM USING 'copy c:\source\*.* c:\target\' #s where #s returns the status of the call. I ran the sqr but the return status is always 2 (which indicates an error) and nothing gets copied over to the target Can someone shed some light in this area. Thanks From owner-sqr-users@list.iex.net Wed Jul 7 10:03:58 1999 Date: Wed, 7 Jul 1999 09:59:59 -0400 From: "David M. Thelen" Subject: Re: Question on CALL SYSTEM I don't recall all the details behind the system call but this was the suggestion I received a while back and has worked well for me. LET $COMMAND = GETENV('COMSPEC') || ' /c copy c:\source\*.* c:\target\*.*' call system using $COMMAND #s I think you could probably get more details on this from the archives but I'm have a CRS day. Anthony Leung-New York wrote: > Dear all, > > I have a sqr that is running on a Windows 95 environment. I need to do a > CALL SYSTEM to copy files from one directory to another. According to the > SQR Reference book the syntax should be as follow: > > CALL SYSTEM USING 'copy c:\source\*.* c:\target\' #s > > where #s returns the status of the call. > > I ran the sqr but the return status is always 2 (which indicates an error) > and nothing gets copied over to the target > > Can someone shed some light in this area. > > Thanks From owner-sqr-users@list.iex.net Wed Jul 7 09:53:28 1999 Date: Wed, 7 Jul 1999 07:31:47 -0700 From: Vince Mancino Subject: Re: Error adding subrecord to PS_JOB If the sub record has any peoplecode you must bypass it. The most common way is to add a panelgroup test at the top of the current peoplecode and bypass if not equal. If you have any peoplecode test add it after the else. Also review the sub record for any required fields. Zubin Shroff wrote: > We added a subrecord to the PS_JOB table. The fields from the > subrecord were added to the Hire panels. However, when trying to hire > an employee, before any of the panels load, the following PeopleCode > error occurs: > > "Invalid parameter 1 for CurrentRowNumber function" > > - Is there some peoplecode I need to add/remove/modify when adding a > subrecord to job? > > - Do fields from a subrecord need to be on a subpanel? They are > currently on the main hire panels, and we were wondering if that had > something to do with the error. > > Any help will be appreciated. > > Thanks. -- Vince Mancino - Consultant E5D4@EARTHLINK.NET From owner-sqr-users@list.iex.net Wed Jul 7 09:58:16 1999 Date: Wed, 7 Jul 1999 07:47:06 -0700 From: Joe Subject: Re: select works in SQL but not in SQR Thanks to all for your help! The problem was addressed by your collective suggestions and some pesky date formats in other parts of the SQR. Long live SQRUG! ~~ JEJ ~~ ;{) -------------------------------------------------------- $14.95 Unlimited Internet Access, http://www.surfree.com From owner-sqr-users@list.iex.net Wed Jul 7 11:43:50 1999 Date: Wed, 7 Jul 1999 09:35:54 -0700 From: Kris Narravula Subject: Re: Crossposting This is a multi-part message in MIME format. ------=_NextPart_000_004A_01BEC85C.1C46A1D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everybody, I am getting the postings twice. Anybody else is also receiving the = postings twice or it is to me only. If so what should I do to get rid of = them. Thanks in advance Kris ------=_NextPart_000_004A_01BEC85C.1C46A1D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everybody,
 
I am getting the postings twice. = Anybody else is=20 also receiving the postings twice or it is to me only. If so what = should=20 I do to get rid of them.
 
Thanks in advance
 
Kris
 
------=_NextPart_000_004A_01BEC85C.1C46A1D0-- From owner-sqr-users@list.iex.net Wed Jul 7 12:03:23 1999 Date: Wed, 7 Jul 1999 09:46:54 -0700 From: Joe Subject: SQLPlus question Sorry if this is the wrong group, but the SQRUG has shown itself to be a TOP NOTCH group for help. In Oracle SQL Plus, what (if any) environment optons can be changed to address the error message "input truncated to 16 characters" ? Error occurs in a select statement. TIA ~~ JEJ ~~ ;{) -------------------------------------------------------- $14.95 Unlimited Internet Access, http://www.surfree.com From owner-sqr-users@list.iex.net Wed Jul 7 12:12:50 1999 Date: Wed, 7 Jul 1999 13:01:49 -0400 From: Andy Blakeslee Subject: Re: SQLPlus question Since you kissed up so well, I will resist flaming your off-topic post and risk being flamed myself by answering - there is no setting to change, just make sure to end your sql input file with a carriage return - this signifies "end-of-file" to sqlplus. Thanks, Andy -----Original Message----- From: Joe [mailto:jejohn1216@SURFREE.COM] Sent: Wednesday, July 07, 1999 12:47 PM To: Multiple recipients of list SQR-USERS Subject: SQLPlus question Sorry if this is the wrong group, but the SQRUG has shown itself to be a TOP NOTCH group for help. In Oracle SQL Plus, what (if any) environment optons can be changed to address the error message "input truncated to 16 characters" ? Error occurs in a select statement. TIA ~~ JEJ ~~ ;{) -------------------------------------------------------- $14.95 Unlimited Internet Access, http://www.surfree.com From owner-sqr-users@list.iex.net Wed Jul 7 12:25:33 1999 Date: Wed, 7 Jul 1999 12:09:02 -0500 From: Ray Ontko Subject: Re: Crossposting Kris, If you're SENDING a message and you get it twice, it might be that you're listing yourself as a recipient (cc?) and you're receiving a copy from the list. If you're simply getting two copies of every message SOMEONE ELSE posts to the list, you're possibly subscribed twice to the list (under different e-mail addresses that happen to both get delivered to the same place). Look carefully at the message header and see if you can determine to which address(es) each copy of the message was sent. Or, if you're getting two copies of all messages from outside your company (not just from SQRUG but from other senders as well), you may need to talk to your network administrator. Hope this helps. Ray > Hi everybody, > > I am getting the postings twice. Anybody else is also receiving the postings twice or it is to me only. If so what should I do to get rid of them. > > Thanks in advance > > Kris > ---------------------------------------------------------------------- Ray Ontko | Ray Ontko & Co | "RO&C: data movers and shakers." rayo@ontko.com | Richmond, In | See us at http://www.ontko.com/ From owner-sqr-users@list.iex.net Wed Jul 7 12:51:46 1999 Date: Wed, 7 Jul 1999 12:36:26 -0500 From: Zubin Shroff Subject: Where does SQL get generated for PeopleSoft Inserts? We added a few new fields to the JOB table and on the JOB_DATA_HIRE panels. When adding a new employee, we get a SQL INSERT error since the new fields are not being assigned values. How do I fix this? Where is the SQL generated? Thanks for your help... From owner-sqr-users@list.iex.net Wed Jul 7 14:50:31 1999 Date: Wed, 7 Jul 1999 14:34:29 -0500 From: "Behnke, Greg M" Subject: processing a .dbf file Hello, Has anyone ever had to process a Foxpro file with SQR? How can I strip out the column heading junk at the beginning of the file? TIA Greg Behnke From owner-sqr-users@list.iex.net Wed Jul 7 15:06:03 1999 Date: Wed, 7 Jul 1999 14:49:21 -0500 From: Don Mellen Subject: Re: processing a .dbf file Well, it's been a while since I played with .DBF files, but as I recall, there was an initial value that told you the size of the header portion, along with the # of records, etc. Once you find these values (they're in pre-set positions with pre-set sizes I belive), you should be able to parse out the rest of the header info for field names, types, sizes, etc. and use this to determine how to read the rest of the file. Sorry for the vagueness, but like I said, it's been awhile HTH, Don On Wed, 7 Jul 1999, Behnke, Greg M wrote: > Hello, > Has anyone ever had to process a Foxpro file with SQR? How can I strip out > the column heading junk at the beginning of the file? > TIA > > Greg Behnke > ----------------------------------------------------------------------- Donald Mellen | Ray Ontko & Co. - Richmond, IN - http://www.ontko.com/ donm@ontko.com | "In the beginning, there was nothing, which exploded" From owner-sqr-users@list.iex.net Wed Jul 7 17:19:35 1999 Date: Wed, 7 Jul 1999 18:06:11 -0400 From: S+A Sills Subject: Re: processing a .dbf file take a look at the stuff in http://www.egroups.com/docvault/psusers/ folder named sqr to write dbf file for excel , access this will ident how to write a dbf file. it also has a descr of a dbf version VI file format. this amy give some hints on how to read. you will be able to address the field descriptor array and the start of data. From owner-sqr-users@list.iex.net Wed Jul 7 18:05:08 1999 Date: Wed, 7 Jul 1999 16:52:45 -0600 From: Jason Thiessen Subject: SQR contract resource needed This is a multi-part message in MIME format. ------=_NextPart_000_0119_01BEC899.23492420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I run an IT staffing and contracting firm in Calgary, Alberta, Canada. = I have a client in need of an SQR resource for a contract role until he = end of August. The client has about a half dozen reports that need work = and they need someone ASAP. Can anyone out there help me find someone = who may be interested in this and available? ------=_NextPart_000_0119_01BEC899.23492420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I run an IT staffing and contracting = firm in=20 Calgary, Alberta, Canada.  I have a client in need of an SQR = resource for a=20 contract role until he end of August.  The client has about a half = dozen=20 reports that need work and they need someone ASAP.  Can anyone out = there=20 help me find someone who may be interested in this and=20 available?
------=_NextPart_000_0119_01BEC899.23492420-- From owner-sqr-users@list.iex.net Fri Jul 9 20:46:12 1999 Date: Thu, 8 Jul 1999 03:35:35 +0100 From: Franck Masson Subject: Re: Mailing SQR report from unix i have tried your command from unix prompt and shell script. I got the same result. It works . i have done the test on solaris 2.6 try to do this : mail root < file.uuencode go to /usr/mail and copy the root file to root.old execute the same command in a shell script and compare the file root and root.old to see if there are difference franck, Karimundackal, Liz J. wrote: > > Thanks for the suggestion, but the SQR program will be kicked off by a unix > script in the night, > so there is no means of running elm interactively and moreover I do not have > elm!! > I tried to send the mail from a Unix Shell script but the same problem > occurs. > I tried a : uuencode letter.htm letter.htm | mail lkari@jjjj.com > It send the uuencoded characters as the text of the message!! > I would really like to know why something that works perfectly from the > command prompt will not work from SQR or Unix shell script!! > > Thanks for all the help. > > -----Original Message----- > From: Warner, Dave (CCB) [SMTP:warnerd@WDNI.COM] > Sent: Friday, July 09, 1999 2:27 PM > To: Multiple recipients of list SQR-USERS > Subject: Re: Mailing SQR report from unix > > If you have elm installed you can send attachments like this: > > let $command = 'echo "[include /tmp/file1.txt text/plain]\n[include > /tmp/file2.pdf application/pdf]" | elm -s "Subject" > email@address.com' > call system using $command #mail_status > > More files can be included with a \n separating them. > > The user who is running the SQR must first run elm once > interactively before > it can be run in "batch mode" like this. > > Elm takes care of the uuencoding for you, unlike mail or mailx. > > > ---------- > > From: Karimundackal, Liz > J.[SMTP:lkarimundackal@JHANCOCK.COM] > > Subject: Mailing SQR report from unix > > > > Hi all, > > I am trying to mail the report created by my SQR program > from the > > same program. > > My code is : > > let $command = 'uuencode letter.htm letter.htm > letter.uue' > > call system using $command #encode_status > > let $command = 'mail lkarimundackal@jhancock.com < letter.uue' > > call system using $command #mail_status > > > > My intention is to send the report as an attachment. I tried the > uuencode > > and the mail command > > from the unix prompt and it worked great, but when I do the same > commands > > from SQR, the > > encoded file goes as text, so the mail has a lot of junk as the > text. All > > the files, including the uuencoded > > file is created properly from SQR and both commands have a success > return > > code. > > > > Any help will be appreciated. > > Thanks in advance, > > Liz J Karimundackal > > (617) 572-8288 > > e-mail : lkarimundackal@jhancock.com > > From owner-sqr-users@list.iex.net Wed Jul 7 22:30:11 1999 Date: Thu, 8 Jul 1999 10:16:44 +0700 From: Hartono Sutirman Subject: Re: Where does SQL get generated for PeopleSoft Inserts? hi... As far as I know, you can assign default values to the fields but it is not required, since peoplesoft would automatically insert a space to a blank field. This error usually happen because you haven't Alter or Re-Create the Table after you added the fields and maybe you want to check the Setting when you choose to re-create or alter the table. regards, Hartono Sutirman Zubin Shroff wrote: > We added a few new fields to the JOB table and on the JOB_DATA_HIRE > panels. When adding a new employee, we get a SQL INSERT error since > the new fields are not being assigned values. How do I fix this? Where > is the SQL generated? > > Thanks for your help... From owner-sqr-users@list.iex.net Wed Jul 7 22:39:11 1999 Date: Wed, 7 Jul 1999 20:28:10 PDT From: nitin rathor Subject: Re: Where does SQL get generated for PeopleSoft Inserts? may be the insert error is due to field constraint at database level ??????? quite a possibility , please check. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-sqr-users@list.iex.net Thu Jul 8 06:00:32 1999 Date: Thu, 8 Jul 1999 17:48:26 +0700 From: Hartono Sutirman Subject: How to Execute Excel from SQR ?? Hi gurus..... I have created SQR that produces a tab-delimiter file and then I need to open it in Excel SpreadSheet. How Can I call the Excel from the SQR ??? So when the SQR finishes produce the output, I want to call Excel and open the output file in excel ?? I've tried the Call System, but still cannot work. any suggestion would very appreciated !! regards Hartono Sutirman From owner-sqr-users@list.iex.net Thu Jul 8 07:03:49 1999 Date: Thu, 8 Jul 1999 07:47:30 -0400 From: Anthony Leung-New York Subject: SQR on SQL 7.0 Dear all, I was told that SQR has a performance issue when running on SQL 7.0. Is it a fact? Rumors was that SQR may run several times slower from SQL 6.5 to SQL 7.0. Is anyone using SQR SQL 7.0 yet? We are trying to decide if we should upgrade from SQL 6.5 to 7.0. Thanks in advance. Anthony Leung From owner-sqr-users@list.iex.net Thu Jul 8 08:09:45 1999 Date: Thu, 8 Jul 1999 07:52:03 -0500 From: John Letts Subject: Re: SQR contract resource needed Good Morning Jason: I have two SQR people available. One is SQR/PeopleSoft/Conversions and Interfaces and the other is specifically SQR. If you are interested, please advise. I can forward their profiles immediately. I am in sales for a medium sized (225 consultants) PeopleSoft consulting firm in Chicago. John > -----Original Message----- > From: Jason Thiessen [SMTP:jthiesse@HVLD.COM] > Sent: Wednesday, July 07, 1999 5:53 PM > To: Multiple recipients of list SQR-USERS > Subject: SQR contract resource needed > > I run an IT staffing and contracting firm in Calgary, Alberta, Canada. I > have a client in need of an SQR resource for a contract role until he end > of August. The client has about a half dozen reports that need work and > they need someone ASAP. Can anyone out there help me find someone who may > be interested in this and available? From owner-sqr-users@list.iex.net Thu Jul 8 07:58:48 1999 Date: Thu, 8 Jul 1999 07:56:24 -0500 From: "Maikranz, Sheila R." Subject: Re: SQR on SQL 7.0 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BEC941.2A80CC36 Content-Type: text/plain; charset="iso-8859-1" Anthony, We upgraded to MSSQL7 and have not experienced any slow down in times that are notable. If you are using PeopleSoft, you may based on the modules that you have, need to create some views manually after the upgrade. Hope this helps. Sheila -----Original Message----- From: Anthony Leung-New York [mailto:ALeung@RUSSREYN.COM] Sent: Thursday, July 08, 1999 6:48 AM To: Multiple recipients of list SQR-USERS Subject: SQR on SQL 7.0 Dear all, I was told that SQR has a performance issue when running on SQL 7.0. Is it a fact? Rumors was that SQR may run several times slower from SQL 6.5 to SQL 7.0. Is anyone using SQR SQL 7.0 yet? We are trying to decide if we should upgrade from SQL 6.5 to 7.0. Thanks in advance. Anthony Leung ------_=_NextPart_001_01BEC941.2A80CC36 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: SQR on SQL 7.0

Anthony,

We upgraded to MSSQL7 and have not experienced any = slow down in times that are notable.  If you are using PeopleSoft, = you may based on the modules that you have, need to create some views = manually after the upgrade.

Hope this helps.

Sheila

-----Original Message-----
From: Anthony Leung-New York [mailto:ALeung@RUSSREYN.COM]
Sent: Thursday, July 08, 1999 6:48 AM
To: Multiple recipients of list SQR-USERS
Subject: SQR on SQL 7.0



Dear all,

I was told that SQR has a performance issue when = running on SQL 7.0.  Is it
a fact? Rumors was that  SQR may run several = times slower from SQL 6.5 to
SQL 7.0.

Is anyone using SQR SQL 7.0 yet? We are trying to = decide if we should
upgrade from SQL 6.5 to 7.0.

Thanks in advance.

Anthony Leung

------_=_NextPart_001_01BEC941.2A80CC36-- From owner-sqr-users@list.iex.net Thu Jul 8 08:40:36 1999 Date: Thu, 8 Jul 1999 07:18:40 -0600 From: Juan Alvarado Subject: Re: How to Execute Excel from SQR ?? You can try the CVS option , that produce a button in the report that when run the report a push the button automatic startup excel or whatever you have relation with and cvs. I hope this help you -----Original Message----- From: Hartono Sutirman [mailto:hsutirman@JATIS.COM] Sent: Thursday, July 08, 1999 4:48 AM To: Multiple recipients of list SQR-USERS Subject: How to Execute Excel from SQR ?? Hi gurus..... I have created SQR that produces a tab-delimiter file and then I need to open it in Excel SpreadSheet. How Can I call the Excel from the SQR ??? So when the SQR finishes produce the output, I want to call Excel and open the output file in excel ?? I've tried the Call System, but still cannot work. any suggestion would very appreciated !! regards Hartono Sutirman From owner-sqr-users@list.iex.net Thu Jul 8 09:30:35 1999 Date: Thu, 8 Jul 1999 09:14:10 -0500 From: Gracen Duffield Subject: Re: How to Execute Excel from SQR ?? have you tried this (i don't know if it will work): 1. export data comma delimited file with a .cvs extension 2. write a batch file that launches excel and passes it the .cvs file to open the syntax (i think) is [full path of excel.exe] [full path of input file] example: C:\Program Files\MSOffice\Office\excel.exe c:\work\data.cvs 3. use call system to call the batch file from the sqr. Gracen Duffield Texas Department of Housing and Community Affairs 475-3839 -----Original Message----- From: Juan Alvarado [mailto:juan@GYSSA.COM.GT] Sent: Thursday, July 08, 1999 8:19 AM To: Multiple recipients of list SQR-USERS Subject: Re: How to Execute Excel from SQR ?? You can try the CVS option , that produce a button in the report that when run the report a push the button automatic startup excel or whatever you have relation with and cvs. I hope this help you -----Original Message----- From: Hartono Sutirman [mailto:hsutirman@JATIS.COM] Sent: Thursday, July 08, 1999 4:48 AM To: Multiple recipients of list SQR-USERS Subject: How to Execute Excel from SQR ?? Hi gurus..... I have created SQR that produces a tab-delimiter file and then I need to open it in Excel SpreadSheet. How Can I call the Excel from the SQR ??? So when the SQR finishes produce the output, I want to call Excel and open the output file in excel ?? I've tried the Call System, but still cannot work. any suggestion would very appreciated !! regards Hartono Sutirman From owner-sqr-users@list.iex.net Thu Jul 8 09:43:22 1999 Date: Thu, 8 Jul 1999 09:31:34 -0500 From: Nathan Stratton Treadway Subject: Re: SQLPlus question On Wed, Jul 07, 1999 at 09:46:54AM -0700, Joe wrote: > In Oracle SQL Plus, what (if any) environment optons can be changed to > address the error message "input truncated to 16 characters" ? > > Error occurs in a select statement. Are you trying to run a "script file" with @ or "start"? I've seen this message if the script file did not have a carriage-return /line-feed (or just line-feed under Unix) on the last line. SQL*Plus assumes this means that the file was truncated somehow, and prints the above the message as a warning. If this is your situation, you'll find that the last line of the script file is 16 characters long. You can get rid of the message by making sure the last line of the script file gets properly terminated. Many text editors will automatically do this; you would just need to open the file and then save it again. If your editor doesn't do this, you might need to manually hit at the end of the file, or something. Or, under Unix you should be able to just say echo >> script.sql (Be sure to have two ">" or you'll erase your script!) The "echo" will generate a proper line termination sequence, which will then be appended to the script. Hope this helps. Nathan ---------------------------------------------------------------------------- Nathan Stratton Treadway | Ray Ontko & Co. | Software consulting services nathant@ontko.com | Richmond, IN | http://www.ontko.com/ From owner-sqr-users@list.iex.net Thu Jul 8 10:29:16 1999 Date: Thu, 8 Jul 1999 08:13:37 -0700 From: John Sayre Subject: Re: How to Execute Excel from SQR ?? From: John Sayre@GAPINC on 07/08/99 08:13 AM I have been able to do this with the following commands: LET $CALLSTR='X:\MSOFFICE\EXCEL.EXE -S H:\EXCEL\FORMAT.XLS' CALL SYSTEM USING $CALLSTR #RETURN_VALUE Please respond to SQR-USERS@list.iex.net To: Multiple recipients of list SQR-USERS cc: (bcc: John Sayre/SB/GAPINC) Subject: How to Execute Excel from SQR ?? Hi gurus..... I have created SQR that produces a tab-delimiter file and then I need to open it in Excel SpreadSheet. How Can I call the Excel from the SQR ??? So when the SQR finishes produce the output, I want to call Excel and open the output file in excel ?? I've tried the Call System, but still cannot work. any suggestion would very appreciated !! regards Hartono Sutirman From owner-sqr-users@list.iex.net Thu Jul 8 11:30:20 1999 Date: Thu, 8 Jul 1999 12:13:35 -0400 From: Rosie ODonnell Subject: Re: How to Execute Excel from SQR ?? John, I just tried your solution in a program that I am working on, and it works perfectly. I have one additional question. I used your example to launch excel and open the csv file that my sqr created. Excel launches and opens the file, but the sqrw communications box is still open in the background with the 'End of Run' message displayed. Is there a routine that my program can call that would automatically close the communications box immediatly after the 'CALL SYSTEM' line? Joe Patton Marconi Communications John Sayre on 07/08/99 11:13:37 AM Please respond to SQR-USERS@list.iex.net To: Multiple recipients of list SQR-USERS cc: (bcc: Joe Patton/LLP/RELTECCORP) Subject: Re: How to Execute Excel from SQR ?? From: John Sayre@GAPINC on 07/08/99 08:13 AM I have been able to do this with the following commands: LET $CALLSTR='X:\MSOFFICE\EXCEL.EXE -S H:\EXCEL\FORMAT.XLS' CALL SYSTEM USING $CALLSTR #RETURN_VALUE Please respond to SQR-USERS@list.iex.net To: Multiple recipients of list SQR-USERS cc: (bcc: John Sayre/SB/GAPINC) Subject: How to Execute Excel from SQR ?? Hi gurus..... I have created SQR that produces a tab-delimiter file and then I need to open it in Excel SpreadSheet. How Can I call the Excel from the SQR ??? So when the SQR finishes produce the output, I want to call Excel and open the output file in excel ?? I've tried the Call System, but still cannot work. any suggestion would very appreciated !! regards Hartono Sutirman From owner-sqr-users@list.iex.net Thu Jul 8 12:49:35 1999 Date: Thu, 8 Jul 1999 09:44:03 -0700 From: Clara Carter Subject: Re: How to Execute Excel from SQR ?? Hi, I didn't know sqr could do this so I just learned something new but I am wondering why or what would you use this for? Clara At 12:13 PM 7/8/99 -0400, you wrote: >John, > >I just tried your solution in a program that I am working on, and it works >perfectly. I have one additional question. I used your example to launch >excel >and open the csv file that my sqr created. Excel launches and opens the file, >but the sqrw communications box is still open in the background with the >'End of >Run' message displayed. Is there a routine that my program can call that would >automatically close the communications box immediatly after the 'CALL SYSTEM' >line? > >Joe Patton >Marconi Communications > > > > >John Sayre on 07/08/99 11:13:37 AM > >Please respond to SQR-USERS@list.iex.net > >To: Multiple recipients of list SQR-USERS >cc: (bcc: Joe Patton/LLP/RELTECCORP) > >Subject: Re: How to Execute Excel from SQR ?? > > > > >From: John Sayre@GAPINC on 07/08/99 08:13 AM >I have been able to do this with the following commands: > >LET $CALLSTR='X:\MSOFFICE\EXCEL.EXE -S H:\EXCEL\FORMAT.XLS' >CALL SYSTEM USING $CALLSTR #RETURN_VALUE > > > > > > > >Please respond to SQR-USERS@list.iex.net > >To: Multiple recipients of list SQR-USERS >cc: (bcc: John Sayre/SB/GAPINC) >Subject: How to Execute Excel from SQR ?? > > > > >Hi gurus..... > >I have created SQR that produces a tab-delimiter file and then I need to open >it in Excel SpreadSheet. >How Can I call the Excel from the SQR ??? >So when the SQR finishes produce the output, I want to call Excel and open the >output file in excel ?? >I've tried the Call System, but still cannot work. > >any suggestion would very appreciated !! > >regards >Hartono Sutirman From owner-sqr-users@list.iex.net Thu Jul 8 12:46:37 1999 Date: Thu, 8 Jul 1999 12:32:40 -0500 From: Zubin Shroff Subject: Prompt table not working in Correction mode I have created a custom prompt table which works fine in Update/Display and Add modes. However, when I go into Correction mode, the prompt table opens up but does not display any values. Any ideas? Thanks! From owner-sqr-users@list.iex.net Thu Jul 8 12:45:06 1999 Date: Thu, 8 Jul 1999 10:33:10 -0700 From: "Ormond, Travis R" Subject: Fonts - Excel vs. SQR I am trying to duplicate an Excel template using SQR. The spreadsheet uses Arial 6 & 14-pt font. I'm printing to an HP Laserjet 4000 N printer. The device settings for the printer indicate that Helvetica will be substituted for Arial. My SQR contains the following: BEGIN-SETUP declare-printer hpdef type=hplaserjet symbol-set=0U ! ASCII symbol set point-size=6 font=4 !Helvetica font available in SQR for HP LaserJet printer types end-declare declare-report default printer-type=hplaserjet end-declare alter-printer font=4 point-size=14 END-SETUP BEGIN-HEADING 1 Print 'TEST FONT OUTPUT' (1,5) bold END-HEADING I ran the SQR from SQRW (version 4.3.2) using the -Flpt1 flag. LPT1 is mapped to a networked, HP printer. Unfortunately, the letters printed from the SQR are slightly larger & wider than what is printed from Excel. It does appear to be using the correct font, but the size does not match. Does anyone have an idea why this might occur? How can I make the output from these 2 programs look exactly alike? Thanks a lot. Travis From owner-sqr-users@list.iex.net Thu Jul 8 13:02:03 1999 Date: Thu, 8 Jul 1999 12:44:28 -0500 From: Debra Benton Subject: Syntax question - how do you continue to the next line on a load lookup where clause? Hopefully this is an easy syntax question: My load-lookup has a lengthy where clause that I would like to put on several lines to make it easier to read in the future. How can I continue on the next line? I've tried the underscore at the end of the line with no success. Thanks, Debbie load-lookup name=RGN-DESCR table=PS_SUBCUST_Q1_TBL key=SUBCUST_QUAL1 return_value=DESCR where='EFFDT = (SELECT MAX(A_ED.EFFDT) FROM PS_SUBCUST_Q1_TBL A_ED WHERE SETID = A_ED.SETID AND SUBCUST_QUAL1 = A_ED.SUBCUST_QUAL1 AND A_ED.EFFDT <= SYSDATE) AND SETID = ''CIS00''' From owner-sqr-users@list.iex.net Thu Jul 8 12:57:52 1999 Date: Thu, 8 Jul 1999 10:46:15 -0700 From: "Shaver, Richard H" Subject: Updating from &variables I received the following missive from a very persistent programmer. I would like to know if anybody else is aware of this problem or has any comments regarding it. TIA Rick I have discovered that updating records in SQL Server 6.5 using Visual Sqribe 4.3 with Microsoft ODBC drivers can corrupt records. This happens when a SQR - SQL procedure updates a field in a record with a Null value using an &variable. For example, the following SQR will corrupt the Equipment table record. The XACTION record, (xkey = '100001'), has a Null value in PPERMAREA and the procedure will update EQ5 to that value in PPERMAREA using &PAREA BEGIN-PROGRAM BEGIN-SELECT PPERMAREA &PAREA FROM XACTION WHERE XKEY = '100001' END-SELECT BEGIN-SQL UPDATE EQUIPMENT SET DESCRIPTION = 'TESTED SQR UPDATE', EQ5 = &PAREA WHERE EQNUM = '115274'; COMMIT END-SQL END-PROGRAM After executing this SQR if I try to view the record using Enterprise Manager (iSQL) all the fields following EQ5 in the select statement appear to be blank. But they are not blank. If I put the fields that appear blank before EQ5 in the select statement, then I can see their contents. When I examine the contents of a corrupted EQ5, using the statement "Select ASCII(SUBSTRING(EQ5,1,1)), a zero is displayed. If I execute this statement against a record that has not been corrupted and has a Null EQ5, I get , not a zero. I know the ASCII representation of Null is zero but.... I contacted Sqribe and they said "SQR has no concept of Nulls". (Huh? - what is the IsNull function for then?) They said that we should use an SQL Server function to test for a Null value, store some character in a program defined variable to indicate Null, (i.e. $variable), then when updating or storing test that variable for the character indicating Null and use an SQL Server function to actually store a Null value. Whew, I don't think I'd like having to do that for every field. I found that by first moving the &variable to a $variable, and then updating the record using the $variable, that the Null value is stored correctly and the record is not corrupted. When I try to run a SQL Update procedure within SQR against the corrupted records I get an SQR error "003735, Could not execute SQL" - but the same statement works against records that were not corrupted. I find this kind of weird since the error description says the error occured while trying to compile the statement. I'm going to using the $variable method unless someone has a better idea. From owner-sqr-users@list.iex.net Thu Jul 8 13:28:18 1999 Date: Thu, 8 Jul 1999 13:49:02 -0400 From: "Sarabudla, Raji R." Subject: Re: How to Execute Excel from SQR ?? Use -XCB flag in SQR Command line Flag, it prevents use of communication box. It pops up the windows dialog box, only when inputs are present in the SQR program. Hope it helps, Raji ---------- From: Rosie ODonnell [SMTP:joe.patton@NA.MARCONICOMMS.COM] Sent: Thursday, July 08, 1999 12:14 PM To: Multiple recipients of list SQR-USERS Subject: Re: How to Execute Excel from SQR ?? John, I just tried your solution in a program that I am working on, and it works perfectly. I have one additional question. I used your example to launch excel and open the csv file that my sqr created. Excel launches and opens the file, but the sqrw communications box is still open in the background with the 'End of Run' message displayed. Is there a routine that my program can call that would automatically close the communications box immediatly after the 'CALL SYSTEM' line? Joe Patton Marconi Communications John Sayre on 07/08/99 11:13:37 AM Please respond to SQR-USERS@list.iex.net To: Multiple recipients of list SQR-USERS cc: (bcc: Joe Patton/LLP/RELTECCORP) Subject: Re: How to Execute Excel from SQR ?? From: John Sayre@GAPINC on 07/08/99 08:13 AM I have been able to do this with the following commands: LET $CALLSTR='X:\MSOFFICE\EXCEL.EXE -S H:\EXCEL\FORMAT.XLS' CALL SYSTEM USING $CALLSTR #RETURN_VALUE Please respond to SQR-USERS@list.iex.net To: Multiple recipients of list SQR-USERS cc: (bcc: John Sayre/SB/GAPINC) Subject: How to Execute Excel from SQR ?? Hi gurus..... I have created SQR that produces a tab-delimiter file and then I need to open it in Excel SpreadSheet. How Can I call the Excel from the SQR ??? So when the SQR finishes produce the output, I want to call Excel and open the output file in excel ?? I've tried the Call System, but still cannot work. any suggestion would very appreciated !! regards Hartono Sutirman From owner-sqr-users@list.iex.net Thu Jul 8 13:03:17 1999 Date: Thu, 8 Jul 1999 10:51:26 -0700 From: Pankaj Bedekar Subject: Re: Prompt table not working in Correction mode This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BEC96A.8139568C Content-Type: text/plain; charset="iso-8859-1" is that table is effective dated ? if no ... no need of using correction mode pankaj -----Original Message----- From: Zubin Shroff [mailto:zshroff@DTTUS.COM] Sent: Thursday, July 08, 1999 10:33 AM To: Multiple recipients of list SQR-USERS Subject: Prompt table not working in Correction mode I have created a custom prompt table which works fine in Update/Display and Add modes. However, when I go into Correction mode, the prompt table opens up but does not display any values. Any ideas? Thanks! ------_=_NextPart_001_01BEC96A.8139568C Content-Type: text/html; charset="iso-8859-1" RE: Prompt table not working in Correction mode

is that table is effective dated ? if no ... no need of using  correction mode

pankaj

-----Original Message-----
From: Zubin Shroff [mailto:zshroff@DTTUS.COM]
Sent: Thursday, July 08, 1999 10:33 AM
To: Multiple recipients of list SQR-USERS
Subject: Prompt table not working in Correction mode


     I have created a custom prompt table which works fine in
     Update/Display and Add modes. However, when I go into Correction mode,
     the prompt table opens up but does not display any values.

     Any ideas?

     Thanks!

------_=_NextPart_001_01BEC96A.8139568C-- From owner-sqr-users@list.iex.net Thu Jul 8 13:15:07 1999 Date: Thu, 8 Jul 1999 12:54:24 -0500 From: Nathan Stratton Treadway Subject: Re: Prompt table not working in Correction mode On Thu, Jul 08, 1999 at 12:32:40PM -0500, Zubin Shroff wrote: > I have created a custom prompt table which works fine in > Update/Display and Add modes. However, when I go into Correction mode, > the prompt table opens up but does not display any values. This question doesn't related to SQR; you should ask it in the PeopleSoft list (see http://www.egroups.com/list/psusers/info.html ), where people are more likely to have experienced this particular problem. Nathan Stratton Treadway sqr-users list manager ---------------------------------------------------------------------------- Nathan Stratton Treadway | Ray Ontko & Co. | Software consulting services nathant@ontko.com | Richmond, IN | http://www.ontko.com/ From owner-sqr-users@list.iex.net Thu Jul 8 14:02:03 1999 Date: Thu, 8 Jul 1999 11:30:31 -0700 From: Pankaj Bedekar Subject: Re: Syntax question - how do you continue to the next line on a l oad lookup where clause? This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BEC96F.FBE85414 Content-Type: text/plain; charset="iso-8859-1" how about using - at end of line and starting at next line ... '-' is use as continuation -----Original Message----- From: Debra Benton [mailto:debra.benton@NPAC.COM] Sent: Thursday, July 08, 1999 10:44 AM To: Multiple recipients of list SQR-USERS Subject: Syntax question - how do you continue to the next line on a load lookup where clause? Hopefully this is an easy syntax question: My load-lookup has a lengthy where clause that I would like to put on several lines to make it easier to read in the future. How can I continue on the next line? I've tried the underscore at the end of the line with no success. Thanks, Debbie load-lookup name=RGN-DESCR table=PS_SUBCUST_Q1_TBL key=SUBCUST_QUAL1 return_value=DESCR where='EFFDT = (SELECT MAX(A_ED.EFFDT) FROM PS_SUBCUST_Q1_TBL A_ED WHERE SETID = A_ED.SETID AND SUBCUST_QUAL1 = A_ED.SUBCUST_QUAL1 AND A_ED.EFFDT <= SYSDATE) AND SETID = ''CIS00''' ------_=_NextPart_001_01BEC96F.FBE85414 Content-Type: text/html; charset="iso-8859-1" RE: Syntax question - how do you continue to the next line on a load lookup where clause?

how about using - at end of line and starting at next line ...
'-' is use as continuation

-----Original Message-----
From: Debra Benton [mailto:debra.benton@NPAC.COM]
Sent: Thursday, July 08, 1999 10:44 AM
To: Multiple recipients of list SQR-USERS
Subject: Syntax question - how do you continue to the next line on a
load lookup where clause?


Hopefully this is an easy syntax question:

My load-lookup has a lengthy where clause that I would like to put on
several lines to make it easier to read in the future.  How can I continue
on the next line?  I've tried the underscore at the end of the line with no
success.

Thanks,
Debbie

load-lookup
  name=RGN-DESCR
    table=PS_SUBCUST_Q1_TBL
    key=SUBCUST_QUAL1
    return_value=DESCR
    where='EFFDT = (SELECT MAX(A_ED.EFFDT) FROM PS_SUBCUST_Q1_TBL A_ED WHERE
SETID = A_ED.SETID AND SUBCUST_QUAL1 = A_ED.SUBCUST_QUAL1 AND A_ED.EFFDT <=
SYSDATE) AND SETID = ''CIS00'''

------_=_NextPart_001_01BEC96F.FBE85414-- From owner-sqr-users@list.iex.net Thu Jul 8 14:14:57 1999 Date: Thu, 8 Jul 1999 11:48:57 -0700 From: John Sayre Subject: Re: How to Execute Excel from SQR ?? From: John Sayre@GAPINC on 07/08/99 11:48 AM In my case, our HR admin people need to create list of people at review time and their current salary information & most recent promotion information. We are ~125,000 full & PT employees. There is a tree structure in how our cost centers roll up to our 8 divisions. The HR admin people plug a division into a PS panel which runs a SQR. The SQR creates a text file for each cost center in the division. Then we run Excel, and open , automatically, a spreadsheet with an auto_run macro. This spreadsheet opens each of the text files just created, converts each text file into an spreadsheet, saves the spread sheet and then deletes the text files. The new mini-spreadsheets, 1 per cost center, are emailed to the manager of the cost center. This saves the HR admin folks from having to manually open a bunch a text files in Excel, maniplulate them and save them. Also we can format them really pretty on the fly and easily set protection on fields that should not be changed. In general, our users hate .lis files and convert them to Excel, anyway. I just wrote a general purpose XLS to open any text file we write from SQR and format it for the users with no intervention on their part. Please respond to SQR-USERS@list.iex.net To: Multiple recipients of list SQR-USERS cc: (bcc: John Sayre/SB/GAPINC) Subject: Re: How to Execute Excel from SQR ?? Hi, I didn't know sqr could do this so I just learned something new but I am wondering why or what would you use this for? Clara At 12:13 PM 7/8/99 -0400, you wrote: >John, > >I just tried your solution in a program that I am working on, and it works >perfectly. I have one additional question. I used your example to launch >excel >and open the csv file that my sqr created. Excel launches and opens the file, >but the sqrw communications box is still open in the background with the >'End of >Run' message displayed. Is there a routine that my program can call that would >automatically close the communications box immediatly after the 'CALL SYSTEM' >line? > >Joe Patton >Marconi Communications > > > > >John Sayre on 07/08/99 11:13:37 AM > >Please respond to SQR-USERS@list.iex.net > >To: Multiple recipients of list SQR-USERS >cc: (bcc: Joe Patton/LLP/RELTECCORP) > >Subject: Re: How to Execute Excel from SQR ?? > > > > >From: John Sayre@GAPINC on 07/08/99 08:13 AM >I have been able to do this with the following commands: > >LET $CALLSTR='X:\MSOFFICE\EXCEL.EXE -S H:\EXCEL\FORMAT.XLS' >CALL SYSTEM USING $CALLSTR #RETURN_VALUE > > > > > > > >Please respond to SQR-USERS@list.iex.net > >To: Multiple recipients of list SQR-USERS >cc: (bcc: John Sayre/SB/GAPINC) >Subject: How to Execute Excel from SQR ?? > > > > >Hi gurus..... > >I have created SQR that produces a tab-delimiter file and then I need to open >it in Excel SpreadSheet. >How Can I call the Excel from the SQR ??? >So when the SQR finishes produce the output, I want to call Excel and open the >output file in excel ?? >I've tried the Call System, but still cannot work. > >any suggestion would very appreciated !! > >regards >Hartono Sutirman From owner-sqr-users@list.iex.net Thu Jul 8 14:25:18 1999 Date: Thu, 8 Jul 1999 14:04:55 -0500 From: Debra Benton Subject: Re: Syntax question - how do you continue to the next line on a l oad lookup where clause? Thank you for the suggestion.  Unfortunately, I still receive the following errors:   Error in include file "C:\debbie\invoices\bifulp03.sqc" on line 2757:    (SQR 3501) Did not find end of literal. 'EFFDT = (SELECT MAX(A_ED.EFFDT) -   Error in include file "C:\debbie\invoices\bifulp03.sqc" on line 2758:    (SQR 4115) Unknown command or extra parameters found (missing quotes?).     FROM PS_BI_TYPE A_ED WHERE SETID = A_ED.SETID AND BILL_TYPE_ID = A_ED.BILL_TYPE_ID AND A_ED.EFFDT <= SYSDATE) AND SETID = ''CIS00'''   Errors were found in the program file.   SQR: Program Aborting.   Thanks again, Debbie     -----Original Message----- From: Pankaj Bedekar [mailto:BedekarP@ALCONEMARKETING.COM] Sent: Thursday, July 08, 1999 2:31 PM To: Multiple recipients of list SQR-USERS Subject: Re: Syntax question - how do you continue to the next line on a l oad lookup where clause? how about using - at end of line and starting at next line ... '-' is use as continuation -----Original Message----- From: Debra Benton [ mailto:debra.benton@NPAC.COM ] Sent: Thursday, July 08, 1999 10:44 AM To: Multiple recipients of list SQR-USERS Subject: Syntax question - how do you continue to the next line on a load lookup where clause? Hopefully this is an easy syntax question: My load-lookup has a lengthy where clause that I would like to put on several lines to make it easier to read in the future.  How can I continue on the next line?  I've tried the underscore at the end of the line with no success. Thanks, Debbie load-lookup   name=RGN-DESCR     table=PS_SUBCUST_Q1_TBL     key=SUBCUST_QUAL1     return_value=DESCR     where='EFFDT = (SELECT MAX(A_ED.EFFDT) FROM PS_SUBCUST_Q1_TBL A_ED WHERE SETID = A_ED.SETID AND SUBCUST_QUAL1 = A_ED.SUBCUST_QUAL1 AND A_ED.EFFDT <= SYSDATE) AND SETID = ''CIS00''' From owner-sqr-users@list.iex.net Thu Jul 8 14:45:24 1999 Date: Thu, 8 Jul 1999 12:32:30 -0700 From: Pankaj Bedekar Subject: Re: Syntax question - how do you continue to the next line on a l oad lookup where clause? This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BEC978.9EB0BC56 Content-Type: text/plain; charset="iso-8859-1" sorry but how about using substitution .... where = [$text_where] -----Original Message----- From: Debra Benton [mailto:debra.benton@NPAC.COM] Sent: Thursday, July 08, 1999 12:05 PM To: Multiple recipients of list SQR-USERS Subject: Re: Syntax question - how do you continue to the next line on a l oad lookup where clause? Thank you for the suggestion. Unfortunately, I still receive the following errors: Error in include file "C:\debbie\invoices\bifulp03.sqc" on line 2757: (SQR 3501) Did not find end of literal. 'EFFDT = (SELECT MAX(A_ED.EFFDT) - Error in include file "C:\debbie\invoices\bifulp03.sqc" on line 2758: (SQR 4115) Unknown command or extra parameters found (missing quotes?). FROM PS_BI_TYPE A_ED WHERE SETID = A_ED.SETID AND BILL_TYPE_ID = A_ED.BILL_TYPE_ID AND A_ED.EFFDT <= SYSDATE) AND SETID = ''CIS00''' Errors were found in the program file. SQR: Program Aborting. Thanks again, Debbie -----Original Message----- From: Pankaj Bedekar [mailto:BedekarP@ALCONEMARKETING.COM] Sent: Thursday, July 08, 1999 2:31 PM To: Multiple recipients of list SQR-USERS Subject: Re: Syntax question - how do you continue to the next line on a l oad lookup where clause? how about using - at end of line and starting at next line ... '-' is use as continuation -----Original Message----- From: Debra Benton [ mailto:debra.benton@NPAC.COM ] Sent: Thursday, July 08, 1999 10:44 AM To: Multiple recipients of list SQR-USERS Subject: Syntax question - how do you continue to the next line on a load lookup where clause? Hopefully this is an easy syntax question: My load-lookup has a lengthy where clause that I would like to put on several lines to make it easier to read in the future. How can I continue on the next line? I've tried the underscore at the end of the line with no success. Thanks, Debbie load-lookup name=RGN-DESCR table=PS_SUBCUST_Q1_TBL key=SUBCUST_QUAL1 return_value=DESCR where='EFFDT = (SELECT MAX(A_ED.EFFDT) FROM PS_SUBCUST_Q1_TBL A_ED WHERE SETID = A_ED.SETID AND SUBCUST_QUAL1 = A_ED.SUBCUST_QUAL1 AND A_ED.EFFDT <= SYSDATE) AND SETID = ''CIS00''' ------_=_NextPart_001_01BEC978.9EB0BC56 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Syntax question - how do you continue to the next line on a = l oad lookup where clause?

sorry but how about using substitution ....
where =3D [$text_where]



-----Original Message-----
From: Debra Benton [mailto:debra.benton@NPAC.COM]<= /FONT>
Sent: Thursday, July 08, 1999 12:05 PM
To: Multiple recipients of list SQR-USERS
Subject: Re: Syntax question - how do you continue = to the next line on a
l oad lookup where clause?


Thank you for the suggestion.=A0 Unfortunately, I = still receive the following
errors:
=A0
Error in include file = "C:\debbie\invoices\bifulp03.sqc" on line 2757:
=A0=A0 (SQR 3501) Did not find end of = literal.
'EFFDT =3D (SELECT MAX(A_ED.EFFDT) -
=A0
Error in include file = "C:\debbie\invoices\bifulp03.sqc" on line 2758:
=A0=A0 (SQR 4115) Unknown command or extra = parameters found (missing quotes?).
=A0=A0=A0 FROM PS_BI_TYPE A_ED WHERE SETID =3D = A_ED.SETID AND BILL_TYPE_ID =3D
A_ED.BILL_TYPE_ID AND A_ED.EFFDT <=3D SYSDATE) = AND SETID =3D ''CIS00'''
=A0
Errors were found in the program file.
=A0
SQR: Program Aborting.
=A0
Thanks again,
Debbie
=A0

=A0

-----Original Message-----
From: Pankaj Bedekar [mailto:BedekarP@ALCONEMARKE= TING.COM]
Sent: Thursday, July 08, 1999 2:31 PM
To: Multiple recipients of list SQR-USERS
Subject: Re: Syntax question - how do you continue = to the next line on a l
oad lookup where clause?



how about using - at end of line and starting at next = line ...
'-' is use as continuation

-----Original Message-----
From: Debra Benton [ mailto:debra.benton@NPAC.COM
<mailto:debra.benton@NPAC.COM&g= t; ]
Sent: Thursday, July 08, 1999 10:44 AM
To: Multiple recipients of list SQR-USERS
Subject: Syntax question - how do you continue to = the next line on a
load lookup where clause?


Hopefully this is an easy syntax question:

My load-lookup has a lengthy where clause that I = would like to put on
several lines to make it easier to read in the = future.=A0 How can I continue
on the next line?=A0 I've tried the underscore at = the end of the line with no
success.

Thanks,
Debbie

load-lookup
=A0 name=3DRGN-DESCR
=A0=A0=A0 table=3DPS_SUBCUST_Q1_TBL
=A0=A0=A0 key=3DSUBCUST_QUAL1
=A0=A0=A0 return_value=3DDESCR
=A0=A0=A0 where=3D'EFFDT =3D (SELECT MAX(A_ED.EFFDT) = FROM PS_SUBCUST_Q1_TBL A_ED WHERE

SETID =3D A_ED.SETID AND SUBCUST_QUAL1 =3D = A_ED.SUBCUST_QUAL1 AND A_ED.EFFDT <=3D
SYSDATE) AND SETID =3D ''CIS00'''

------_=_NextPart_001_01BEC978.9EB0BC56-- From owner-sqr-users@list.iex.net Thu Jul 8 14:50:10 1999 Date: Thu, 8 Jul 1999 15:32:59 -0400 From: Sheeja John Subject: Using a Rollback Segment within a SQR Hi -- I'm trying to specify a name of a rollback segment within a SQR. The SQR is an interface that inserts records into temporary tables and quite often it errors because of the rollback segment being small. (The inserts are in 10,000's ). I tried using 'DBMS_TRANSACTION.USE_ROLLBACK_SEGMENT("RBIG") to choose the biggest available rollback segment, but does not work. Does anybody have any input on this ? Any kind of input is appreciated .... Thanks Sheeja From owner-sqr-users@list.iex.net Thu Jul 8 15:13:35 1999 Date: Thu, 8 Jul 1999 14:47:08 -0500 From: Kenny Melton Subject: Re: Using a Rollback Segment within a SQR Sheeja, If you are using an Oracle database, try this: BEGIN-SQL SET TRANSACTION USE ROLLBACK SEGMENT RBIG END-SQL Where RBIG is an actual segment name (that is on-line, of course). I have used this with success. Remember that a "commit" ends the transaction, so you must issue the above statement after each explicit commit in the program. Good Luck, Kenny -----Original Message----- From: Sheeja John [mailto:Sjohn@LYDALL.COM] Sent: Thursday, July 08, 1999 2:33 PM To: Multiple recipients of list SQR-USERS Subject: Using a Rollback Segment within a SQR Hi -- I'm trying to specify a name of a rollback segment within a SQR. The SQR is an interface that inserts records into temporary tables and quite often it errors because of the rollback segment being small. (The inserts are in 10,000's ). I tried using 'DBMS_TRANSACTION.USE_ROLLBACK_SEGMENT("RBIG") to choose the biggest available rollback segment, but does not work. Does anybody have any input on this ? Any kind of input is appreciated .... Thanks Sheeja From owner-sqr-users@list.iex.net Thu Jul 8 15:10:24 1999 Date: Thu, 8 Jul 1999 15:57:51 -0400 From: "Wanko, Christopher G, CFCTR" Subject: Re: Syntax question - how do you continue to the next line on a l oad lookup where clause? > Hopefully this is an easy syntax question: > where='EFFDT = (SELECT MAX(A_ED.EFFDT) FROM PS_SUBCUST_Q1_TBL A_ED WHERE > SETID = A_ED.SETID AND SUBCUST_QUAL1 = A_ED.SUBCUST_QUAL1 AND > A_ED.EFFDT <= SYSDATE) AND SETID = ''CIS00''' Whew. I couldn't trust myself to get that right every time. I'd be lazy and code this: where [$where] Of course, I'd still have to do the work somewhere. I'd probably say something like this further up in the code, before the main SELECT: let $where = 'EFFDT = (SELECT MAX(A_ED.EFFDT) FROM PS_SUBCUST_Q1_TBL A_ED WHERE ' let $where = $where || 'SETID = A_ED.SETID AND SUBCUST_QUAL1 = A_ED.SUBCUST_QUAL1 AND ' let $where = $where || 'A_ED.EFFDT <= SYSDATE) AND SETID = ' || '''' || 'CIS00' || '''' I'm sure this crude example can be surpassed in beauty and style, but it works and gets me home by 1630hrs. -Chris From owner-sqr-users@list.iex.net Thu Jul 8 16:49:58 1999 Date: Thu, 8 Jul 1999 14:36:46 -0700 From: David Donnelly Subject: Re: Updating from &variables Dear Rick, The whole problem of empty variables and whether they are "null" or contain zero-length strings is a difficult and platform-dependent one. In Oracle, with SQL*Net and not ODBC, I have never had any problem: when I pass a value that you would consider "null" because it was returned from a null database value, Oracle understands that it is null and correctly sets it so. I think this is because (at least with varchar2 types through Oracle 7), zero-length strings are not recorded in the database. Ingres does not. I have often ended up with zero-length strings in character variables. It seems to work OK for numeric type; I've never ended up with zero (or anything else) in a field that should have been null. I don't have any experience with ODBC on either platform. I am a little surprised that &variables and $variables work differently. What Sqribe meant with the remark about nulls was a little confusing, as I think they were talking about the ASCII character "nul" (value 00) and not the concept of a null value in a database field. In at least the Oracle implementation, strings are implemented as ordinary C character strings, which means that they are terminated by the character nul (00). Character-type &variables seem to be initialized to the null string, and there is no way to differentiate between variables that are "empty" because the query has never been executed, because the returned value was "null", or other more subtle situations (e.g. substr(field,...)) where the field contained something but the substring evaluates to "nothing" ... is that "null" or a zero-length string or what?). Two workarounds come to mind. When performance is not an issue, I do this: if isnull(&col) ! or maybe if (length(&col) = 0) let $var = 'null' else let $var = '''' || &col || '''' end-if - - - update tablename set fieldname = [$var] This works, but will be recompiled every time it's executed, with the accompanying performance hit. If you've got a lot of rows, but the data isn't needed until later (I mean you're not doing a multi-user thing where someone could fetch your new row the next instant) then you might be able just to do whatever you do now, and fix the data later by something like update tablename set fieldname = null where length(fieldname) = 0 Hope this helps. Dave At 10:46 AM 7/8/1999 -0700, you wrote: >I received the following missive from a very persistent programmer. I would >like to know if anybody else is aware of this problem or has any comments >regarding it. >TIA >Rick > > >I have discovered that updating records in SQL Server 6.5 using Visual >Sqribe 4.3 with Microsoft ODBC drivers can corrupt records. This happens >when a SQR - SQL procedure updates a field in a record with a Null value >using an &variable. >For example, the following SQR will corrupt the Equipment table record. The >XACTION record, (xkey = '100001'), has a Null value in PPERMAREA and the >procedure will update EQ5 to that value in PPERMAREA using &PAREA >BEGIN-PROGRAM >BEGIN-SELECT >PPERMAREA &PAREA > FROM XACTION > WHERE XKEY = '100001' >END-SELECT >BEGIN-SQL >UPDATE EQUIPMENT > SET DESCRIPTION = 'TESTED SQR UPDATE', EQ5 = &PAREA WHERE EQNUM = >'115274'; >COMMIT >END-SQL >END-PROGRAM > > >After executing this SQR if I try to view the record using Enterprise >Manager (iSQL) all the fields following EQ5 in the select statement appear >to be blank. But they are not blank. If I put the fields that appear blank >before EQ5 in the select statement, then I can see their contents. >When I examine the contents of a corrupted EQ5, using the statement "Select >ASCII(SUBSTRING(EQ5,1,1)), a zero is displayed. If I execute this statement >against a record that has not been corrupted and has a Null EQ5, I get >, not a zero. I know the ASCII representation of Null is zero but.... >I contacted Sqribe and they said "SQR has no concept of Nulls". (Huh? - >what is the IsNull function for then?) They said that we should use an SQL >Server function to test for a Null value, store some character in a program >defined variable to indicate Null, (i.e. $variable), then when updating or >storing test that variable for the character indicating Null and use an SQL >Server function to actually store a Null value. >Whew, I don't think I'd like having to do that for every field. >I found that by first moving the &variable to a $variable, and then updating >the record using the $variable, that the Null value is stored correctly and >the record is not corrupted. >When I try to run a SQL Update procedure within SQR against the corrupted >records I get an SQR error "003735, Could not execute SQL" - but the same >statement works against records that were not corrupted. I find this kind >of weird since the error description says the error occured while trying to >compile the statement. >I'm going to using the $variable method unless someone has a better idea. > From owner-sqr-users@list.iex.net Thu Jul 8 17:35:12 1999 Date: Thu, 8 Jul 1999 16:12:32 -0600 From: Juan Alvarado Subject: Re: Updating from &variables We use sqr for sybase and odbc and what we saw thru our expirence en both plataforms is the odbc have parameters that if you dont configure correctly with your application, show problems that affect the correct function of the system or in the best of cases show problems of the sintaxis of sqr. May be your problem is the configuration of odbc. We never saw corruption of the data when you do a update thru sqr, but we sar others problems. I hope this help you -----Original Message----- From: Shaver, Richard H [mailto:richard.h.shaver@LMCO.COM] Sent: Thursday, July 08, 1999 11:46 AM To: Multiple recipients of list SQR-USERS Subject: Updating from &variables I received the following missive from a very persistent programmer. I would like to know if anybody else is aware of this problem or has any comments regarding it. TIA Rick I have discovered that updating records in SQL Server 6.5 using Visual Sqribe 4.3 with Microsoft ODBC drivers can corrupt records. This happens when a SQR - SQL procedure updates a field in a record with a Null value using an &variable. For example, the following SQR will corrupt the Equipment table record. The XACTION record, (xkey = '100001'), has a Null value in PPERMAREA and the procedure will update EQ5 to that value in PPERMAREA using &PAREA BEGIN-PROGRAM BEGIN-SELECT PPERMAREA &PAREA FROM XACTION WHERE XKEY = '100001' END-SELECT BEGIN-SQL UPDATE EQUIPMENT SET DESCRIPTION = 'TESTED SQR UPDATE', EQ5 = &PAREA WHERE EQNUM = '115274'; COMMIT END-SQL END-PROGRAM After executing this SQR if I try to view the record using Enterprise Manager (iSQL) all the fields following EQ5 in the select statement appear to be blank. But they are not blank. If I put the fields that appear blank before EQ5 in the select statement, then I can see their contents. When I examine the contents of a corrupted EQ5, using the statement "Select ASCII(SUBSTRING(EQ5,1,1)), a zero is displayed. If I execute this statement against a record that has not been corrupted and has a Null EQ5, I get , not a zero. I know the ASCII representation of Null is zero but.... I contacted Sqribe and they said "SQR has no concept of Nulls". (Huh? - what is the IsNull function for then?) They said that we should use an SQL Server function to test for a Null value, store some character in a program defined variable to indicate Null, (i.e. $variable), then when updating or storing test that variable for the character indicating Null and use an SQL Server function to actually store a Null value. Whew, I don't think I'd like having to do that for every field. I found that by first moving the &variable to a $variable, and then updating the record using the $variable, that the Null value is stored correctly and the record is not corrupted. When I try to run a SQL Update procedure within SQR against the corrupted records I get an SQR error "003735, Could not execute SQL" - but the same statement works against records that were not corrupted. I find this kind of weird since the error description says the error occured while trying to compile the statement. I'm going to using the $variable method unless someone has a better idea. From owner-sqr-users@list.iex.net Fri Jul 9 06:00:18 1999 Date: Fri, 9 Jul 1999 06:47:42 -0400 From: TD Subject: Re: Prompt table not working in Correction mode Zubin, Are you accessing 'history' rows while in correction mode?... or are you referring to the 'same' row you're accessing in Update/Display... If it's a history row look at the effective date... Then see if the prompt table is effective dated... If the history effdt is prior to any of the prompt table effective dates (meaning the prompt values did not exist at that particular point in time) then the prompt list will be empty... It would be helpful to have the RECNAME, FIELDNAME and PNLNAME you're referring to... -Tony DeLia PS - Nathan's right... this is strictly PeopleSoft without any SQR-related issues... By the way, special thanks to Nathan for updating my link with my new site address... I appreciate it! Nathan Stratton Treadway wrote: > On Thu, Jul 08, 1999 at 12:32:40PM -0500, Zubin Shroff wrote: > > I have created a custom prompt table which works fine in > > Update/Display and Add modes. However, when I go into Correction mode, > > the prompt table opens up but does not display any values. > > This question doesn't related to SQR; you should ask it in the > PeopleSoft list (see http://www.egroups.com/list/psusers/info.html ), > where people are more likely to have experienced this particular > problem. > > Nathan Stratton Treadway > sqr-users list manager > ---------------------------------------------------------------------------- > Nathan Stratton Treadway | Ray Ontko & Co. | Software consulting services > nathant@ontko.com | Richmond, IN | http://www.ontko.com/ -- Tony DeLia AnswerThink Consulting Group PeopleSoft Solutions Practice - Delphi Partners tdelia@erols.com http://www.sqrtools.com From owner-sqr-users@list.iex.net Fri Jul 9 06:46:39 1999 Date: Fri, 9 Jul 1999 18:31:21 +0700 From: Hartono Sutirman Subject: How to Execute Excel from SQR ?? - Solved Thank you for all your suggestion. Finally I solved the problem. The command I use is : LET $COMMAND = GETENV('COMSPEC') || ' /c EXCEL.EXE C:\TEMP\REPORT.LIS' CALL SYSTEM USING $COMMAND #S By the way, I using SQR 4.3 on ORACLE 7.3.3 database and the Operating System is Windows NT 4.0 thanks everyone.... regards, Hartono Sutirman Nathan Stratton Treadway wrote: > On Thu, Jul 08, 1999 at 05:48:26PM +0700, Hartono Sutirman wrote: > > How Can I call the Excel from the SQR ??? > > So when the SQR finishes produce the output, I want to call Excel and open the > > output file in excel ?? > > I've tried the Call System, but still cannot work. > > You haven't given the list enough information to help you. > > You'll probably have better luck if you include the following > information in your post to the mailing list: > * what version of SQR you are using > * what operating system you are running on > * what you have tried to do (you might want to include the > lines of your SQR program related to your problem) > * what you mean by "still cannot work". (Did you get an error > message? Did the SQR program run but Excel simply did not start?) > > It should be possible to do what you want, I think, but you'll have to > give us more information before we can tell you what's wrong.... > > (Please post another message to the mailing list with this information.) > > Good luck. > > Nathan > > ---------------------------------------------------------------------------- > Nathan Stratton Treadway | Ray Ontko & Co. | Software consulting services > nathant@ontko.com | Richmond, IN | http://www.ontko.com/ From owner-sqr-users@list.iex.net Fri Jul 9 10:55:51 1999 Date: Fri, 9 Jul 1999 09:01:45 -0500 From: David Ward Subject: FTP From SQR Hello, everyone. I've been sitting back quietly reading all the information posted on this list for the last few months, and have really been impressed with the technical knowledge of the members. I have an issue I'm trying to develop a solution for..... Has anyone ever fired off an FTP process from within an SQR, or created an external program to do an FTP on the client, which is then called from an SQR? Thank you. David Ward Technology & Information Resources UW-Whitewater 800 W. Main St. Whitewater, WI 53190 E-mail: wardd@uwwvax.uww.edu Voice: 414-472-1039 Fax: 414-472-5733 From owner-sqr-users@list.iex.net Fri Jul 9 09:41:14 1999 Date: Fri, 9 Jul 1999 10:19:59 -0400 From: "Karimundackal, Liz J." Subject: Mailing SQR report from unix Hi all, I am trying to mail the report created by my SQR program from the same program. My code is : let $command = 'uuencode letter.htm letter.htm > letter.uue' call system using $command #encode_status let $command = 'mail lkarimundackal@jhancock.com < letter.uue' call system using $command #mail_status My intention is to send the report as an attachment. I tried the uuencode and the mail command from the unix prompt and it worked great, but when I do the same commands from SQR, the encoded file goes as text, so the mail has a lot of junk as the text. All the files, including the uuencoded file is created properly from SQR and both commands have a success return code. Any help will be appreciated. Thanks in advance, Liz J Karimundackal (617) 572-8288 e-mail : lkarimundackal@jhancock.com From owner-sqr-users@list.iex.net Fri Jul 9 10:14:49 1999 Date: Fri, 9 Jul 1999 10:44:40 -0400 From: "Dray, Adam" Subject: Re: FTP From SQR [David Ward asks how to do FTP from within SQR. If that's not what he's asking, oops.] I've created batch files for FTP processes under Windows, so I can help a little. You'll have to check the syntax for the version of FTP that you are using, and you can expect differences if you're trying to FTP under UNIX. Under UNIX, you might consider other file transfer options, such as rcp. Create a script for the FTP session. Here's an example: open mymachine.myhost.com user myusername mypassword ascii cd /export/data1/cam_load put MYFILE.DAT myfile.dat quit The script contains commands you'd type in any interactive FTP session, with the special note that your username and password for the session follow the 'user' command (each on a separate line). Next, set up your SQR program to call the FTP program with the pre- defined script. Under Windows, you can create a batch file like this: @echo off echo FTPing files... ftp.exe -n -s:myscript.ftp > ftp.log echo Done. Check email for confirmation of job runs. Of course, you don't need a batch file. You can just put the ftp.exe command directly into your CALL statement in the SQR. Next, call the batch file (or a shell script equivalent in UNIX), or just call the ftp program directly. ! under Windows Let $command = getenv('COMSPEC') || '/c ' Let $command = $command || 'ftp.exe -n -s:myscript.ftp > ftp.log' Call System Using $command #status ! under UNIX Let $command = 'ftp < myscript.ftp > ftp.log' Call System Using $command #status You probably should use full path names to files, and you should definitely check #status and do something on error. Caveat emptor: I have not actually tried any of this from SQR, so the Call System code might be dysfunctional. Check the archives for recent posts on calling external commands from different operating systems. Hope this helps. Adam Dray From owner-sqr-users@list.iex.net Fri Jul 9 10:24:23 1999 Date: Fri, 9 Jul 1999 09:53:21 -0500 From: Gracen Duffield Subject: Re: Mailing SQR report from unix it might be the extra space: .... = '.... < letter.uue' try .... = '.... Subject: "freebie" code / random number generator. seeing as how it only took me about 1 hour of research (i looked at other generators and saw how they worked) and maybe 2 hours of trial-and-error coding, i have no qualms about giving this code away... i know many of you have asked for a decent random number generator, since SQR and Oracle both DO NOT have a RND function built-in... so here's one i wrote. it's not your typical generator. it uses the system clock for the initial seeds (two), counts how many iterations have been performed, refreshes the seeds every 1000 iterations... the new seeds includes factors from the previous ones. it also keeps track of how many times it has "missed" while trying to generate a new unique number, and uses this value in creating the next candidate. and, continuously, each new number plays a role in altering one of the two seeds upon each iteration. oh yeah and there's something else, minor - but probably still important as to why it works rather well - the reason i use two seeds is because the second seed includes a multiplicand of the previous value of the first seed. so the second seed "inherits" properties of the first one, before it changed again. basically, it's as complicated as you can get without sacrificing calculation performance. the driver code (in the "program" section) calls the other three procedures to generate and store 5000 unique 5 digit (range: 0 to 99999) numbers... ... in under 3 minutes. (on a P133, even.) not to shabby, if i do say so myself. the generated numbers obtained by the generator are stored in a database table called "random_values". without further adieu, the code: -- begin-setup begin-sql create table random_values (N number) end-sql end-setup begin-program let #RNDINIT=0 ! initialization flag let #RNDITER=0 ! counts # of iterations let #RNDSEED1=0 ! seed 1 let #RNDSEED2=0 ! seed 2 let #RNDEXISTS=0 ! used by checkRandom let #RNDMISSES=0 ! number of "misses"; used in regenerating seed let #RNDVALUE=0 ! where the new random value is stored let #RNDRANGE=100000 ! upper range of generated integer let #NUM=5000 ! number of randoms to generate let #I=0 ! counter while #I<#NUM do generateRandom do checkRandom while #RNDEXISTS=1 do generateRandom do checkRandom end-while do storeRandom let #I=#I+1 let $D1 = to_char(#RNDVALUE) let $D1 = rpad($D1,8,' ') let $D2 = to_char(#I) let $D3 = $D1 || ': ' || $D2 display $D3 end-while begin-sql commit end-sql ! begin-sql ! drop table random_values ! end-sql ! begin-sql ! commit ! end-sql end-program begin-procedure generateRandom if (#RNDINIT=0) or (#RNDITER=1000) or (#RNDMISSES=100) begin-select to_char(sysdate,'hh:mi:ss') &timen1 to_char(sysdate,'dd-yy') &timen2 let #RNDSEED1 = to_number(substr(&timen1,1,2)) + to_number(substr(&timen1,4,2))*10 + to_number(substr(&timen1,7,2))*100 + #RNDSEED1PREV let #RNDSEED2 = to_number(substr(&timen2,1,2))*100 + to_number(substr(&timen2,4,2))*1000 + #RNDSEED2*#RNDITER from dual end-select let #RNDINIT=1 let #RNDITER=0 let #RNDMISSES=0 end-if let #RNDVALUE=mod(#RNDSEED1+#RNDSEED2+#RNDMISSES,#RNDRANGE) let #RNDSEED1PREV=#RNDSEED1 let #RNDSEED1=mod(#RNDSEED1*#RNDSEED2+#RNDITER,#RNDRANGE*100) let #RNDSEED2=mod(#RNDVALUE*(#RNDSEED1PREV+1),#RNDRANGE*10) let #RNDITER=#RNDITER+1 end-procedure generateRandom begin-procedure checkRandom begin-select count(*) &RNDE let #RNDEXISTS=&RNDE from random_values where N=#RNDVALUE end-select if #RNDEXISTS=0 let #RNDMISSES=0 else let #RNDMISSES=#RNDMISSES+1 end-if end-procedure checkRandom begin-procedure storeRandom begin-sql insert into random_values values (#RNDVALUE) end-sql if mod(#RNDITER,500)=0 ! commit after every 500 inserts begin-sql commit end-sql end-if end-procedure storeRandom -- enjoy! (kris)janis p. gale hrsd - federal reserve bank of new york x8163 From owner-sqr-users@list.iex.net Fri Jul 9 10:27:14 1999 Date: Fri, 9 Jul 1999 11:02:37 -0400 From: "Dray, Adam" Subject: Re: Mailing SQR report from unix The extra space should not matter under any UNIX that I've used. Typically, when you pipe a file into 'mail' using stdin ('<'), the text from the file becomes the body of the message, not an attachment. You are seeing the expected behavior of the mail program. I have no experience sending attachments from the command line using mail or mailx, so I don't have a solution. You might look at other popular mail agents, such as pine or elm, that may be installed on your system. They might be able to send attachments from the command line. Adam > -----Original Message----- > From: Gracen Duffield [SMTP:gduffiel@TDHCA.STATE.TX.US] > Sent: Friday, July 09, 1999 10:53 AM > To: Multiple recipients of list SQR-USERS > Subject: Re: Mailing SQR report from unix > > it might be the extra space: > .... = '.... < letter.uue' > try .... = '.... > Gracen Duffield > Texas Department of Housing and Community Affairs > 475-3839 > > > -----Original Message----- > From: Karimundackal, Liz J. [mailto:lkarimundackal@JHANCOCK.COM] > Sent: Friday, July 09, 1999 9:20 AM > To: Multiple recipients of list SQR-USERS > Subject: Mailing SQR report from unix > > > Hi all, > I am trying to mail the report created by my SQR program from the > same program. > My code is : > let $command = 'uuencode letter.htm letter.htm > letter.uue' > call system using $command #encode_status > let $command = 'mail lkarimundackal@jhancock.com < letter.uue' > call system using $command #mail_status > > My intention is to send the report as an attachment. I tried the uuencode > and the mail command > from the unix prompt and it worked great, but when I do the same commands > from SQR, the > encoded file goes as text, so the mail has a lot of junk as the text. All > the files, including the uuencoded > file is created properly from SQR and both commands have a success return > code. > > Any help will be appreciated. > Thanks in advance, > Liz J Karimundackal > (617) 572-8288 > e-mail : lkarimundackal@jhancock.com From owner-sqr-users@list.iex.net Fri Jul 9 10:42:18 1999 Date: Fri, 9 Jul 1999 08:05:13 -0700 From: Pushparchana Narayana Subject: duplex print command Hi I am trying to print the output of the report on either sides of the paper and used the code as declare-printer hp_printer init-string = <27>&l1s end-declare but it didn't print the output the way I wanted. can anyone help me out by correcting me or by letting me know any other way of doing it. Thanks in advance pushpa _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-sqr-users@list.iex.net Fri Jul 9 13:24:00 1999 Date: Fri, 9 Jul 1999 11:14:13 -0400 From: "Dray, Adam" Subject: Re: "freebie" code / random number generator. [Krisjanis Gale shares some random number generator code.] Neat! What are you using random numbers for? Filling in data on those reports that no one reads anyway? ;) I'd be careful with any RNG that you're using for critical applications (if it's just for your amusement, then it really doesn't matter). RNG's may look like they generate "good" pseudo-random numbers, but many of them don't. Before entrusting an important application to a new RNG, make sure you run some basic statistical analysis on it. Numbers that look very random may start to repeat after a certain number of iterations, may show odd patterns when added together in sequence, and so on. It's a pity that SQR doesn't include a basic rand() function. A system-level function would be many times faster than one written in SQR. 5000 numbers in 3 minutes isn't a lot, but it's not *your* fault SQR is slow. =) Thanks for sharing! From owner-sqr-users@list.iex.net Fri Jul 9 11:39:18 1999 Date: Fri, 9 Jul 1999 11:15:15 -0500 From: Gracen Duffield Subject: Re: FTP From SQR UNIX: Create a script like this: ftp -v -i -n [remote server] < Subject: Re: Mailing SQR report from unix If you have elm installed you can send attachments like this: let $command = 'echo "[include /tmp/file1.txt text/plain]\n[include /tmp/file2.pdf application/pdf]" | elm -s "Subject" email@address.com' call system using $command #mail_status More files can be included with a \n separating them. The user who is running the SQR must first run elm once interactively before it can be run in "batch mode" like this. Elm takes care of the uuencoding for you, unlike mail or mailx. > ---------- > From: Karimundackal, Liz J.[SMTP:lkarimundackal@JHANCOCK.COM] > Subject: Mailing SQR report from unix > > Hi all, > I am trying to mail the report created by my SQR program from the > same program. > My code is : > let $command = 'uuencode letter.htm letter.htm > letter.uue' > call system using $command #encode_status > let $command = 'mail lkarimundackal@jhancock.com < letter.uue' > call system using $command #mail_status > > My intention is to send the report as an attachment. I tried the uuencode > and the mail command > from the unix prompt and it worked great, but when I do the same commands > from SQR, the > encoded file goes as text, so the mail has a lot of junk as the text. All > the files, including the uuencoded > file is created properly from SQR and both commands have a success return > code. > > Any help will be appreciated. > Thanks in advance, > Liz J Karimundackal > (617) 572-8288 > e-mail : lkarimundackal@jhancock.com > From owner-sqr-users@list.iex.net Fri Jul 9 14:22:45 1999 Date: Fri, 9 Jul 1999 14:41:27 -0400 From: Krisjanis Gale Subject: Re: "freebie" code / random number generator. > Neat! What are you using random numbers for? Filling in data on > those reports that no one reads anyway? ;) actually, it's a bit more complex than that =) i just started here some four weeks ago, and already they have me leading (and more or less executing, solo) a project to take all confidential fields in our Production environment and scrambling the heck out of it so we can use the same complement of data in our Development/Test environs, without the worry of personal employee data "leaking" out of the company. i needed the RNG to create a brand new set of EMPLID's for all the existing ones, so that even if we forgot to code up modifications of some of the personal fields, someone STILL couldn't get to an employee's now-semi-garbled data via their Employee ID. > I'd be careful with any RNG that you're using for critical applications > RNG's may look like they generate "good" pseudo-random numbers, but > many of them don't. the distribution/deviation of the numbers isn't so important as having a large set of unique psuedo-random numbers. > run some basic statistical analysis on it. Numbers that look very > random may start to repeat after a certain number of iterations, may > show odd patterns when added together in sequence, and so on. patterns when adding, i can see. but actually the code i distributed creates a table and makes sure it doesn't insert a number it already generated. in theory, given enough time and database storage space, you could generate all the numbers between 0 and specified maximum range (#RNDRANGE), but in a new, random order. > It's a pity that SQR doesn't include a basic rand() function. A > system-level function would be many times faster than one written in > SQR. 5000 numbers in 3 minutes isn't a lot, but it's not *your* fault > SQR is slow. =) that's 5000 *unique* 5-digit randoms in 3 minutes. that's something. what's more is that it generates the first 1000 in 20 seconds ;-) (and of course it slows down exponentially as it starts doing extra iterations to prevent duplicates.) > Thanks for sharing! hey, i've gotten lots of tips here. just investing in its continuing success. (kris)janis p. gale hrsd - federal reserve bank of new york x8163 From owner-sqr-users@list.iex.net Fri Jul 9 14:34:00 1999 Date: Fri, 9 Jul 1999 15:12:09 -0400 From: "Karimundackal, Liz J." Subject: Re: Mailing SQR report from unix Thanks for the suggestion, but the SQR program will be kicked off by a unix script in the night, so there is no means of running elm interactively and moreover I do not have elm!! I tried to send the mail from a Unix Shell script but the same problem occurs. I tried a : uuencode letter.htm letter.htm | mail lkari@jjjj.com It send the uuencoded characters as the text of the message!! I would really like to know why something that works perfectly from the command prompt will not work from SQR or Unix shell script!! Thanks for all the help. -----Original Message----- From: Warner, Dave (CCB) [SMTP:warnerd@WDNI.COM] Sent: Friday, July 09, 1999 2:27 PM To: Multiple recipients of list SQR-USERS Subject: Re: Mailing SQR report from unix If you have elm installed you can send attachments like this: let $command = 'echo "[include /tmp/file1.txt text/plain]\n[include /tmp/file2.pdf application/pdf]" | elm -s "Subject" email@address.com' call system using $command #mail_status More files can be included with a \n separating them. The user who is running the SQR must first run elm once interactively before it can be run in "batch mode" like this. Elm takes care of the uuencoding for you, unlike mail or mailx. > ---------- > From: Karimundackal, Liz J.[SMTP:lkarimundackal@JHANCOCK.COM] > Subject: Mailing SQR report from unix > > Hi all, > I am trying to mail the report created by my SQR program from the > same program. > My code is : > let $command = 'uuencode letter.htm letter.htm > letter.uue' > call system using $command #encode_status > let $command = 'mail lkarimundackal@jhancock.com < letter.uue' > call system using $command #mail_status > > My intention is to send the report as an attachment. I tried the uuencode > and the mail command > from the unix prompt and it worked great, but when I do the same commands > from SQR, the > encoded file goes as text, so the mail has a lot of junk as the text. All > the files, including the uuencoded > file is created properly from SQR and both commands have a success return > code. > > Any help will be appreciated. > Thanks in advance, > Liz J Karimundackal > (617) 572-8288 > e-mail : lkarimundackal@jhancock.com > From owner-sqr-users@list.iex.net Fri Jul 9 15:29:21 1999 Date: Fri, 9 Jul 1999 16:05:51 -0400 From: Ravi Ginjupalli Subject: Re: Mailing SQR report from unix It works from the Unix Shell script. I need to try it from SQR. Ravi. "Karimundackal, Liz J." on 07/09/99 03:12:09 PM Please respond to SQR-USERS@list.iex.net To: Multiple recipients of list SQR-USERS cc: (bcc: Ravi Ginjupalli/HQ/USA/Kelly) Subject: Re: Mailing SQR report from unix Thanks for the suggestion, but the SQR program will be kicked off by a unix script in the night, so there is no means of running elm interactively and moreover I do not have elm!! I tried to send the mail from a Unix Shell script but the same problem occurs. I tried a : uuencode letter.htm letter.htm | mail lkari@jjjj.com It send the uuencoded characters as the text of the message!! I would really like to know why something that works perfectly from the command prompt will not work from SQR or Unix shell script!! Thanks for all the help. -----Original Message----- From: Warner, Dave (CCB) [SMTP:warnerd@WDNI.COM] Sent: Friday, July 09, 1999 2:27 PM To: Multiple recipients of list SQR-USERS Subject: Re: Mailing SQR report from unix If you have elm installed you can send attachments like this: let $command = 'echo "[include /tmp/file1.txt text/plain]\n[include /tmp/file2.pdf application/pdf]" | elm -s "Subject" email@address.com' call system using $command #mail_status More files can be included with a \n separating them. The user who is running the SQR must first run elm once interactively before it can be run in "batch mode" like this. Elm takes care of the uuencoding for you, unlike mail or mailx. > ---------- > From: Karimundackal, Liz J.[SMTP:lkarimundackal@JHANCOCK.COM] > Subject: Mailing SQR report from unix > > Hi all, > I am trying to mail the report created by my SQR program from the > same program. > My code is : > let $command = 'uuencode letter.htm letter.htm > letter.uue' > call system using $command #encode_status > let $command = 'mail lkarimundackal@jhancock.com < letter.uue' > call system using $command #mail_status > > My intention is to send the report as an attachment. I tried the uuencode > and the mail command > from the unix prompt and it worked great, but when I do the same commands > from SQR, the > encoded file goes as text, so the mail has a lot of junk as the text. All > the files, including the uuencoded > file is created properly from SQR and both commands have a success return > code. > > Any help will be appreciated. > Thanks in advance, > Liz J Karimundackal > (617) 572-8288 > e-mail : lkarimundackal@jhancock.com > From owner-sqr-users@list.iex.net Fri Jul 9 15:36:18 1999 Date: Fri, 9 Jul 1999 16:20:20 -0400 From: "Wanko, Christopher G, CFCTR" Subject: Re: "freebie" code / random number generator. > that's 5000 *unique* 5-digit randoms in 3 minutes. > that's something. > what's more is that it generates the first 1000 in 20 seconds ;-) > (and of course it slows down exponentially as it starts > doing extra iterations to prevent duplicates.) Or, you can browse to: http://www.random.org/cgi-bin/randnum?num=10000&min=1&max=50000&col=5 and get 10000 random numbers in 30 seconds, then sort out the duplicates. It sounds like you need a hashing function more than a random function, by the way. -Chris From owner-sqr-users@list.iex.net Fri Jul 9 16:29:02 1999 Date: Fri, 9 Jul 1999 13:40:28 PDT From: Ed Kelly Subject: Re: Syntax question - how do you continue to the next line on a load lookup where clause? You cannot continue a string literal on multiple lines. To accomplish what you are trying to do with the load-lookup command, you have to basic approaches. The approach you choose will probably be influenced by which section of your SQR program is issuing the Load-Lookup command. 1. Use separate substitution variables to define each line of the where clause. Create another Substitution variable to string together all of the line. Use the last substitution variable in your load-lookup where clause. For example: #Define L1 EFFDT = (SELECT MAX(A_ED.EFFDT) #Define L2 FROM PS_SUBCUST_Q1_TBL A_ED #Define L3 WHERE SETID = A_ED.SETID AND #Define L4 SUBCUST_QUAL1 = A_ED.SUBCUST_QUAL1 AND #Define L5 A_ED.EFFDT <= SYSDATE) AND #Define L6 SETID = 'CIS00' #Define MyWhere {L1} {L2} {L3} {L4} {L5} {L6} load-lookup name=RGN-DESCR table=PS_SUBCUST_Q1_TBL key=SUBCUST_QUAL1 return_value=DESCR where='{MyWhere}' Note: This method can be used in any program section. Using this method, your Where clause cannot exceed the SQR line limit (256 characters). 2. Use a string variable for your where clause. Each line of the where clause can be written as a string literal which is concatenated with the rest. Use the string variable in your load-lookup where clause. For example: Let $MyWhere = 'EFFDT = (SELECT MAX(A_ED.EFFDT) ' || 'FROM PS_SUBCUST_Q1_TBL A_ED ' || 'WHERE SETID = A_ED.SETID AND ' || 'SUBCUST_QUAL1 = A_ED.SUBCUST_QUAL1 AND ' || 'A_ED.EFFDT <= SYSDATE) AND ' || 'SETID = ''CIS00''' load-lookup name=RGN-DESCR table=PS_SUBCUST_Q1_TBL key=SUBCUST_QUAL1 return_value=DESCR where=$MyWhere ! Not [$MyWhere] Note: This method can be used in any program section EXCEPT the Setup section. Using this method, your Where clause cannot exceed the SQR string variable limit (3000+ characters). Hope this helps. Ed Kelly >From: Debra Benton >Reply-To: SQR-USERS@list.iex.net >To: Multiple recipients of list SQR-USERS >Subject: Syntax question - how do you continue to the next line on a load > lookup where clause? >Date: Thu, 8 Jul 1999 12:44:28 -0500 > >Hopefully this is an easy syntax question: > >My load-lookup has a lengthy where clause that I would like to put on >several lines to make it easier to read in the future. How can I continue >on the next line? I've tried the underscore at the end of the line with no >success. > >Thanks, >Debbie > >load-lookup > name=RGN-DESCR > table=PS_SUBCUST_Q1_TBL > key=SUBCUST_QUAL1 > return_value=DESCR > where='EFFDT = (SELECT MAX(A_ED.EFFDT) FROM PS_SUBCUST_Q1_TBL A_ED >WHERE >SETID = A_ED.SETID AND SUBCUST_QUAL1 = A_ED.SUBCUST_QUAL1 AND A_ED.EFFDT <= >SYSDATE) AND SETID = ''CIS00''' _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From owner-sqr-users@list.iex.net Fri Jul 9 17:22:46 1999 Date: Fri, 9 Jul 1999 15:06:50 -0700 From: "Warner, Dave (CCB)" Subject: Re: Mailing SQR report from unix Sorry if I wasn't clear. When you run the SQR at night, or whenever, using the command I showed below, it will kick off elm in a batch mode, which does not require user interaction at all. What I meant is that before this "batch mode" will work -- before the the very first time you try it -- you must log in once as the user who will be running the SQR and run elm (by typing 'elm'), so it can create a .elm directory in that user's home directory and do whatever other setup it has to do. I don't think that there is a way to send attachments from mail or mailx. If you pipe a file into a mail command, as your example shows below, it will send the file as the message body. Elm does exactly the same thing, but it has functionality such that your message body can be text which elm interprets and uses to attach files. > ---------- > From: Karimundackal, Liz J.[SMTP:lkarimundackal@JHANCOCK.COM] > Sent: Friday, July 09, 1999 12:12 PM > Subject: Re: Mailing SQR report from unix > > Thanks for the suggestion, but the SQR program will be kicked off by a > unix > script in the night, > so there is no means of running elm interactively and moreover I do not > have > elm!! > I tried to send the mail from a Unix Shell script but the same problem > occurs. > I tried a : uuencode letter.htm letter.htm | mail lkari@jjjj.com > It send the uuencoded characters as the text of the message!! > I would really like to know why something that works perfectly from the > command prompt will not work from SQR or Unix shell script!! > > Thanks for all the help. > > -----Original Message----- > From: Warner, Dave (CCB) [SMTP:warnerd@WDNI.COM] > Sent: Friday, July 09, 1999 2:27 PM > Subject: Re: Mailing SQR report from unix > > If you have elm installed you can send attachments like this: > > let $command = 'echo "[include /tmp/file1.txt > text/plain]\n[include > /tmp/file2.pdf application/pdf]" | elm -s "Subject" > email@address.com' > call system using $command #mail_status > > More files can be included with a \n separating them. > > The user who is running the SQR must first run elm once > interactively before > it can be run in "batch mode" like this. > > Elm takes care of the uuencoding for you, unlike mail or mailx. > > > ---------- > > From: Karimundackal, Liz > J.[SMTP:lkarimundackal@JHANCOCK.COM] > > Subject: Mailing SQR report from unix > > > > Hi all, > > I am trying to mail the report created by my SQR program > from the > > same program. > > My code is : > > let $command = 'uuencode letter.htm letter.htm > letter.uue' > > call system using $command #encode_status > > let $command = 'mail lkarimundackal@jhancock.com < letter.uue' > > call system using $command #mail_status > > > > My intention is to send the report as an attachment. I tried the > uuencode > > and the mail command > > from the unix prompt and it worked great, but when I do the same > commands > > from SQR, the > > encoded file goes as text, so the mail has a lot of junk as the > text. All > > the files, including the uuencoded > > file is created properly from SQR and both commands have a > success > return > > code. > > > > Any help will be appreciated. > > Thanks in advance, > > Liz J Karimundackal > > (617) 572-8288 > > e-mail : lkarimundackal@jhancock.com > > > From owner-sqr-users@list.iex.net Fri Jul 9 18:25:12 1999 Date: Fri, 9 Jul 1999 17:02:25 -0600 From: "Ackerson, Glenn" Subject: Date formatting problem Hello all, It's Friday afternoon, and I must be having mental gridlock on this problem, so please forgive what must sound like a VERY elementary question regarding date formatting. I'm creating a customized version of Peoplesoft's paysheet update SQR (PAYUPDT,) retrieving a date (Pay_End_Dt), and having a problem getting that retrieved date formatted correctly for use in a subsequent Select statement WHERE clause. I could swear I've dealt with this successfully before, but for some reason, I can't seem to hit the mark on this today. Here's the scenario: (1) I get the PAY_END_DT from the pay calendar table (2) I move that retrieved date into a variable $Pay_End_Dt - the date displays with a value such as "1999-06-14" (3) I then try to get the Page# and Line# from the PAY_PAGE table, using the $Pay_End_Dt variable in the WHERE clause. Program execution using the $Pay_End_Dt variable causes the error: (SQR 5528) ORACLE OEXEC error -1843 in cursor 8: ORA-01843: not a valid month I'm assuming that the WHERE clause that's getting an error is expecting the date in native format, namely "dd-mon-yy" (we're using Oracle.) So, I've tried using the Peoplesoft "datetime.sqc" in a variety of formats to convert the date from "yyyy-mm-dd" to native format "dd-mon-yy" and every try has failed. Can anyone provide some assistance on this one? I would be most appreciative. Since I get the SQR listserve messages in digest format, if you wouldn't mind either cc'ing the message to me directly or sending a reply to me directly, that would be great. Thanks for your help! Cheers, Glenn Ackerson ************************************************** Glenn Ackerson Information Technology Professional III Internet Address: gsacker@is.unco.edu University of Northern Colorado Information Services Carter Hall Greeley, CO 80639 From owner-sqr-users@list.iex.net Fri Jul 9 20:15:38 1999 Date: Fri, 9 Jul 1999 16:11:54 -0700 From: Reinier de Ruiter Subject: Re: Date formatting problem Glenn, If you use SQR4 you should use the date type variable and not a string type variable. This way you won't have any problems with formats. If you are using SQR3 you are probably using different formats. Try to use the to_char and to_date functions from oracle to be sure what format the strings are. good luck, Reinier de Ruiter Programmer/Analyst Apollo Group, University of Phoenix Phoenix, Arizona tel:480-557-1158 email work: reinier.deruiter@apollogrp.edu email home: rruiter@yahoo.com -----Original Message----- From: Ackerson, Glenn [mailto:Gsacker@IS.UNCO.EDU] Sent: Friday, July 09, 1999 4:02 PM To: Multiple recipients of list SQR-USERS Subject: Date formatting problem Hello all, It's Friday afternoon, and I must be having mental gridlock on this problem, so please forgive what must sound like a VERY elementary question regarding date formatting. I'm creating a customized version of Peoplesoft's paysheet update SQR (PAYUPDT,) retrieving a date (Pay_End_Dt), and having a problem getting that retrieved date formatted correctly for use in a subsequent Select statement WHERE clause. I could swear I've dealt with this successfully before, but for some reason, I can't seem to hit the mark on this today. Here's the scenario: (1) I get the PAY_END_DT from the pay calendar table (2) I move that retrieved date into a variable $Pay_End_Dt - the date displays with a value such as "1999-06-14" (3) I then try to get the Page# and Line# from the PAY_PAGE table, using the $Pay_End_Dt variable in the WHERE clause. Program execution using the $Pay_End_Dt variable causes the error: (SQR 5528) ORACLE OEXEC error -1843 in cursor 8: ORA-01843: not a valid month I'm assuming that the WHERE clause that's getting an error is expecting the date in native format, namely "dd-mon-yy" (we're using Oracle.) So, I've tried using the Peoplesoft "datetime.sqc" in a variety of formats to convert the date from "yyyy-mm-dd" to native format "dd-mon-yy" and every try has failed. Can anyone provide some assistance on this one? I would be most appreciative. Since I get the SQR listserve messages in digest format, if you wouldn't mind either cc'ing the message to me directly or sending a reply to me directly, that would be great. Thanks for your help! Cheers, Glenn Ackerson ************************************************** Glenn Ackerson Information Technology Professional III Internet Address: gsacker@is.unco.edu University of Northern Colorado Information Services Carter Hall Greeley, CO 80639 From owner-sqr-users@list.iex.net Sat Jul 10 09:29:07 1999 Date: Sat, 10 Jul 1999 08:52:29 -0500 From: Joe Johnson Subject: Re: Date formatting problem Glenn, Check out the Datemath.sqc. It contains a procedure called Convert-FROM-DTU-Date, which should fit your needs (convert YYYY-MM-DD to native format). Good Luck! Joe Johnson jejohn1216@surffree.com -----Original Message----- From: Ackerson, Glenn To: Multiple recipients of list SQR-USERS Date: Friday, July 09, 1999 6:21 PM Subject: Date formatting problem Hello all, It's Friday afternoon, and I must be having mental gridlock on this problem, so please forgive what must sound like a VERY elementary question regarding date formatting. I'm creating a customized version of Peoplesoft's paysheet update SQR (PAYUPDT,) retrieving a date (Pay_End_Dt), and having a problem getting that retrieved date formatted correctly for use in a subsequent Select statement WHERE clause. I could swear I've dealt with this successfully before, but for some reason, I can't seem to hit the mark on this today. Here's the scenario: (1) I get the PAY_END_DT from the pay calendar table (2) I move that retrieved date into a variable $Pay_End_Dt - the date displays with a value such as "1999-06-14" (3) I then try to get the Page# and Line# from the PAY_PAGE table, using the $Pay_End_Dt variable in the WHERE clause. Program execution using the $Pay_End_Dt variable causes the error: (SQR 5528) ORACLE OEXEC error -1843 in cursor 8: ORA-01843: not a valid month I'm assuming that the WHERE clause that's getting an error is expecting the date in native format, namely "dd-mon-yy" (we're using Oracle.) So, I've tried using the Peoplesoft "datetime.sqc" in a variety of formats to convert the date from "yyyy-mm-dd" to native format "dd-mon-yy" and every try has failed. Can anyone provide some assistance on this one? I would be most appreciative. Since I get the SQR listserve messages in digest format, if you wouldn't mind either cc'ing the message to me directly or sending a reply to me directly, that would be great. Thanks for your help! Cheers, Glenn Ackerson ************************************************** Glenn Ackerson Information Technology Professional III Internet Address: gsacker@is.unco.edu University of Northern Colorado Information Services Carter Hall Greeley, CO 80639 From owner-sqr-users@list.iex.net Sat Jul 10 14:11:55 1999 Date: Sat, 10 Jul 1999 14:56:47 -0400 From: Kimberly Lawrence Subject: Re: Mailing SQR report from unix --0__=ct060Fkny7CY9EF2GPTLi5ck0Ko2vbeSYiJkGbsGIzT3TLOZ5tbJi06M Content-type: text/plain; charset=us-ascii Content-Disposition: inline Liz, I've been using this command issued from several SQR's for months now with no problems. I've even used the command to send an email with multiple attachments. No problems. (echo " Text to appear in body of email.\n\n";uuencode /directory/name_of_file_to_attach name_of_attachment_as_it_should_appear_in_the_email) | mailx -m -s "Subject line text" -r "who the email is from" email_address I guess yours would look something like this: (echo " \n\nAttached is the report that you requested.\n\n";uuencode letter.htm letter.htm) | mailx -m -s "SQR report you requested" -r "System Name" lkarimundackal@jhancock.com Feel free to contact me directly if you need any help getting this to work. (Embedded image moved "Karimundackal, Liz J." to file: pic16404.pcx) 07/09/99 10:19 AM Please respond to SQR-USERS@list.iex.net To: Multiple recipients of list SQR-USERS cc: (bcc: Kimberly Lawrence/MIS/Circuit City) Subject: Mailing SQR report from unix Hi all, I am trying to mail the report created by my SQR program from the same program. My code is : let $command = 'uuencode letter.htm letter.htm > letter.uue' call system using $command #encode_status let $command = 'mail lkarimundackal@jhancock.com < letter.uue' call system using $command #mail_status My intention is to send the report as an attachment. I tried the uuencode and the mail command from the unix prompt and it worked great, but when I do the same commands from SQR, the encoded file goes as text, so the mail has a lot of junk as the text. All the files, including the uuencoded file is created properly from SQR and both commands have a success return code. Any help will be appreciated. Thanks in advance, Liz J Karimundackal (617) 572-8288 e-mail : lkarimundackal@jhancock.com --0__=ct060Fkny7CY9EF2GPTLi5ck0Ko2vbeSYiJkGbsGIzT3TLOZ5tbJi06M Content-type: application/octet-stream; name="pic16404.pcx" Content-Disposition: attachment; filename="pic16404.pcx" Content-transfer-encoding: base64 CgUBCAAAAABoACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABaQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPH E8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sT zRPHE8MTwhPwEwzIBgzYE8wTxhPDE8IT7hPOBtcTzBPGE8MTE+wTwgbCBwbCEgbCEgbCEsUG1hPL E8YTwxMT6hMMwgYHwgLCAwISwgfEEsMCwwbVE8sTxRPDExPpE8MGAwcCBwMCwhLDB8ISwgISwgLD BtUTyhPFE8MTE+gTwgIHA8ICEw4DDgLDE8USwwLCEMIG1BPKE8UTwxMT5xMCAwcDAg4TDgITwgIS D8ISD8ISBRICEcICwwbUE8oTxRPCExPmEwYCBwMCDgIOwgLDExITEhPCEg8GxgLDBtMMDAfJE8QT whMT5hMGwwITBgMCDhLFEw8SE8ISBgIDwhIDEsMGB9MDxwwHxRPDExPlEwYHAhESAg8CwhMPwhMP xBMPxRIQwgIDAgMCBtMDxwPEDAfDE8IT4RMHwwzCBgLCEhMCDxLIE8MSD8MSwwIQAwIDBgfSDMkD wgPCDAfCExPbEwfGDMIDDAIHERITEhMSwxMPwxMPwxPDEgIDAgMCwwMCBgzREwfHDMYDDMITE9YT B8UMyAMGB8ICBhLDAsYTEhMSExIPwhIHAgcCAwUQAgYRBgfSE8UTB8QMwgMMwhMT0hMHxAzLA8IM BsISDxESExITAw4DxBMSExITwxICBwPCAsMDDMIGB9ITyRMHwwzCExPPEwfDDMkDxQwHwhMGBxIT AhECEwMOAg7DExITDxMPwxIDAgMCBwMCDAYRBgfSE8kTwhPCDMITE8wTB8MMxwPEDMIHxxMGxBLD Ag4DDgIGwg/IEgIDwgIDAgwCEMIGB9ITyRMHDAcMwhMTyhMHwgzGA8MMwgfMEwYHwhLCEAIOAg4C DhDDAhIPxhIFAgXDAgUCEQYH0hPHEwfCDAcPDMITE8gTB8IMxQPDDAfQEwbDEhDEAhAOEA4QwgLG EgcSBhIGBcMCBcIGB9ATB8UMEwfCDA8HDwwHwhMTxhMHwgzEA8MMB9MTBgfCEhADEMICDhAOEMIC EQIDxxIGBwbCAgUCEQYHyxMHxAwHwhMHEwzCEwcPBw8MB8MTE8UTBwzEA8IMB9YTBsQSEAMCA8UC EQIDAgPDEgcSBgfCBgUQAhDCBgfGEwfEDAfGE8INEwzCEw8HwgwHwxPCE8QTBwzDA8IMB9gTBgfE EhACEMYCEQIDAsQSBhLDBsICEALCBgfCEwfDDAfKEwfCDRMHwhPCDAfEE8ITE8MTBwzCA8IMB9oT DBIHwxLDDBEDxQIDAgPDEgYSBgfCBgIQAhAGDAfCEwzDE8MHyRMHwhPCBxMHxRPDExPDEwzCAwwH 3RMGxxICEQPDAgMCA8MSBhIGBwYMBhACEAIGDMMTDBPCB8YTwwfHEwfGE8MTwhPDEwwDDAfeEwYH xxICEQPDAgMCwhIGEgYHBgwGEAIQAsIGB8MTDMYTwwfKEwzGE8MTwhPDE8IMB98TDBLCB8USAgMR xAISB8ISBgcGDAYQBhAGEAYMB8MMB8kTwwfHEwzGE8MTwhPDEwwPwgzfEwYSB8ISB8ISAhECAwID EgcSBwYHBgwGEAYQxgzDD8IHxRPDB8kTBwzGE8MTwhPDEwzDD8QM3BPCBhIGwxIGAhECAwIHBgcG yAzJDxMHzRMHwwwHxxPDE8ITwxMHDMYPxwwH1BMGEgYSBhLLDM4PwwwTDMcTwgfEDAfJE8QTwhMT xBMHwgzLD9sM0w/GDAfDEwzDEwfEDAfLE8YTwxMTxhMHxAztD8gMBgfIE8QMB84TxxPDE8ITyhMH xwzbD8sMEAUMBcIMwgYH1RPKE8UTwxMT0RMH2wwGEAYQBhACBQwFDAUMBgwHBgfWE8sTxRPDExPu EwYMBhAGEAIGDAYMwwYH1xPLE8YTwxMT8BPKBgfYE8wTxhPDExP1E9sTzRPHE8MTwhP1E9sTzRPH E8MTwhMMAAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD/ /wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8A AAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A //8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAA AP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA /wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCk gICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vw oKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw //vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzA psrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDA wNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICA wMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACA AICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACA gACA//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP////// --0__=ct060Fkny7CY9EF2GPTLi5ck0Ko2vbeSYiJkGbsGIzT3TLOZ5tbJi06M-- From owner-sqr-users@list.iex.net Sat Jul 10 19:33:53 1999 Date: Sat, 10 Jul 1999 16:55:48 -0700 From: Tonie Salzano Subject: Another HTML question --Boundary (ID jj+zlajaTFTvtLK/ivXwmQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit I've got my SQR report making beautiful web pages now. I only have a couple more questions. 1.) How do you control the width of the Table of Contents frame? I'm using: Begin-Heading 2 For-Tocs=(default) Print-Direct printer=html 'Department ID''s' End-Heading This puts a title on the top of the TOC page, but the frame takes up half the page. I want it smaller. 2.) I don't exactly understand how to get the title on the Netscape bar. The books say to use html_set_head_tags but that is not showing up on the top if I use the *_frm.htm file as the frame header. It does work if I just use the *.html page alone. Is there a command like 'Begin-Heading 2 For-Tocs=(default)' to write to the *_frm.htm file?? By the way, the pages are fabulous ;-). The report was over 1300 lines and loaded very slowly, so I did a new-report at the site change and it worked like a charm. I still have to write a header page with all the sites, but the whole program so far is only 370 lines. It's a Paycheck distribution report. Since we have close to 40 sites, we can save printing and bursting by publishing it out on the web. We're using the Mail Drop field to tell where the check is. It has private info on it, but I will be willing to put the source out on the SQRug library when I'm done. Thanks Tonie Salzano Maricopa Community College District --Boundary (ID jj+zlajaTFTvtLK/ivXwmQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7bit

I've got my SQR report making beautiful web pages now.
I only have a couple more questions.

1.) How do you control the width of the Table of Contents
frame? I'm using:
 

Begin-Heading 2 For-Tocs=(default)
   Print-Direct printer=html 'Department ID''s'
End-Heading

This  puts a title on the top of the TOC page, but the frame
takes up half the page. I want it smaller.

2.) I don't exactly understand how to get the title on
the Netscape bar. The books say to use
 

html_set_head_tags

but that is not showing up on the top if I use the *_frm.htm file
as the frame header. It does work if I just use the *.html page alone.

Is there a command like 'Begin-Heading 2 For-Tocs=(default)'
to write to the *_frm.htm file??
 

By the way, the pages are fabulous ;-). The report was over 1300
lines and loaded very slowly, so I did a new-report at the site change
and it worked like a charm. I still have to write a header page with
all the sites, but the whole program so far is only 370 lines.

It's a Paycheck distribution report. Since we have close to 40
sites, we can save printing and bursting by publishing it out on the
web. We're using the Mail Drop field to tell where the check is.
It has private info on it, but I will be willing to put the source out
on the SQRug library when I'm done.
 

Thanks
Tonie Salzano
Maricopa Community College District --Boundary (ID jj+zlajaTFTvtLK/ivXwmQ)-- --Boundary (ID jj+zlajaTFTvtLK/ivXwmQ)-- From owner-sqr-users@list.iex.net Mon Jul 12 06:03:04 1999 Date: Mon, 12 Jul 1999 06:44:04 -0400 From: "Jeffrey K. Bedell" Subject: Re: Mailing SQR report from unix This is a multi-part message in MIME format. --------------4D43D46E24904176F6E31172 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I read the postings from this user group every day and save the ones I find might be useful at some point in the future but have not had occassion to post any questions myself until today. What is elm? -Thanks "Warner, Dave (CCB)" wrote: > If you have elm installed you can send attachments like this: > > let $command = 'echo "[include /tmp/file1.txt text/plain]\n[include > /tmp/file2.pdf application/pdf]" | elm -s "Subject" email@address.com' > call system using $command #mail_status > > More files can be included with a \n separating them. > > The user who is running the SQR must first run elm once interactively before > it can be run in "batch mode" like this. > > Elm takes care of the uuencoding for you, unlike mail or mailx. > > > ---------- > > From: Karimundackal, Liz J.[SMTP:lkarimundackal@JHANCOCK.COM] > > Subject: Mailing SQR report from unix > > > > Hi all, > > I am trying to mail the report created by my SQR program from the > > same program. > > My code is : > > let $command = 'uuencode letter.htm letter.htm > letter.uue' > > call system using $command #encode_status > > let $command = 'mail lkarimundackal@jhancock.com < letter.uue' > > call system using $command #mail_status > > > > My intention is to send the report as an attachment. I tried the uuencode > > and the mail command > > from the unix prompt and it worked great, but when I do the same commands > > from SQR, the > > encoded file goes as text, so the mail has a lot of junk as the text. All > > the files, including the uuencoded > > file is created properly from SQR and both commands have a success return > > code. > > > > Any help will be appreciated. > > Thanks in advance, > > Liz J Karimundackal > > (617) 572-8288 > > e-mail : lkarimundackal@jhancock.com > > --------------4D43D46E24904176F6E31172 Content-Type: text/x-vcard; charset=us-ascii; name="jkbedell.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Jeffrey K. Bedell Content-Disposition: attachment; filename="jkbedell.vcf" begin:vcard n:Bedell;Jeffrey K. tel;fax:(315) 443-3553 tel;work:(315) 443-9273 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:jkbedell@ais.syr.edu x-mozilla-cpt:;31856 fn:Jeffrey K. Bedell end:vcard --------------4D43D46E24904176F6E31172-- From owner-sqr-users@list.iex.net Mon Jul 12 07:48:50 1999 Date: Mon, 12 Jul 1999 08:34:33 -0400 From: "Karimundackal, Liz J." Subject: Re: Mailing SQR report from unix Hi, Thanks a lot.It worked!! I think the problem is mail. I tried the same set of commands with mail and it didn't work. Thanks again for all the help. I really appreciate it. Liz -----Original Message----- From: Kimberly Lawrence [SMTP:Kimberly_Lawrence@CCNOTES.CCITY.COM] Sent: Saturday, July 10, 1999 2:57 PM To: Multiple recipients of list SQR-USERS Subject: Re: Mailing SQR report from unix Liz, I've been using this command issued from several SQR's for months now with no problems. I've even used the command to send an email with multiple attachments. No problems. (echo " Text to appear in body of email.\n\n";uuencode /directory/name_of_file_to_attach name_of_attachment_as_it_should_appear_in_the_email) | mailx -m -s "Subject line text" -r "who the email is from" email_address I guess yours would look something like this: (echo " \n\nAttached is the report that you requested.\n\n";uuencode letter.htm letter.htm) | mailx -m -s "SQR report you requested" -r "System Name" lkarimundackal@jhancock.com Feel free to contact me directly if you need any help getting this to work. (Embedded image moved "Karimundackal, Liz J." to file: pic16404.pcx) 07/09/99 10:19 AM Please respond to SQR-USERS@list.iex.net To: Multiple recipients of list SQR-USERS cc: (bcc: Kimberly Lawrence/MIS/Circuit City) Subject: Mailing SQR report from unix Hi all, I am trying to mail the report created by my SQR program from the same program. My code is : let $command = 'uuencode letter.htm letter.htm > letter.uue' call system using $command #encode_status let $command = 'mail lkarimundackal@jhancock.com < letter.uue' call system using $command #mail_status My intention is to send the report as an attachment. I tried the uuencode and the mail command from the unix prompt and it worked great, but when I do the same commands from SQR, the encoded file goes as text, so the mail has a lot of junk as the text. All the files, including the uuencoded file is created properly from SQR and both commands have a success return code. Any help will be appreciated. Thanks in advance, Liz J Karimundackal (617) 572-8288 e-mail : lkarimundackal@jhancock.com << File: pic16404.pcx >> From owner-sqr-users@list.iex.net Mon Jul 12 08:00:27 1999 Date: Mon, 12 Jul 1999 07:47:06 -0500 From: Julie Waggoner Subject: Re: duplex print command Pushpa, In addition to the init-string you have in the declare-printer section, you also need to specify when to switch printing from the front side to the back side. For the front side: encode '<27>' into $esc let $frontform = $esc || '&a1G' print $frontform () code-printer=hp For the back side: encode '<27>' into $esc let $backform = $esc || '&a2G' print $backform () code-printer=hp I have used these commands in the begin-heading section and used the #page_count reserved variable to switch back and forth between the two commands (when #page_count is odd, use front side, when #page_count is even, use back side). If this doesn't work, you can reference other similar commands under the Simplex/Duplex section of the following HP PCL Command reference page. http://www.hp.com/cposupport/printers/support_doc/bpl02705.html#P86_2004 Julie -----Original Message----- From: Pushparchana Narayana [mailto:pushparchana@YAHOO.COM] Sent: Friday, July 09, 1999 10:05 AM To: Multiple recipients of list SQR-USERS Subject: duplex print command Hi I am trying to print the output of the report on either sides of the paper and used the code as declare-printer hp_printer init-string = <27>&l1s end-declare but it didn't print the output the way I wanted. can anyone help me out by correcting me or by letting me know any other way of doing it. Thanks in advance pushpa _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-sqr-users@list.iex.net Mon Jul 12 08:37:55 1999 Date: Mon, 12 Jul 1999 09:22:08 -0400 From: "Dray, Adam" Subject: Re: Mailing SQR report from unix Wow. Do you really get up that early? Elm and Pine are alternative end-user electronic mail programs (and more) that typically run under UNIX. Both are generally superior to "mail" and "mailx". I found this explanatory guide for Elm: http://mercury.acnet.wnec.edu/net_guides/elm/usr_gd.html Pine is an Elm spin-off with an even easier user interface. "Pine" stands for "Pine Is Not Elm". There's even PC-Pine for Windows. Whee! This seems to be the definitive source: http://www1.cac.washington.edu/pine/ > -----Original Message----- > From: Jeffrey K. Bedell [SMTP:jkbedell@AIS.SYR.EDU] > Sent: Monday, July 12, 1999 6:44 AM > To: Multiple recipients of list SQR-USERS > Subject: Re: Mailing SQR report from unix > > I read the postings from this user group every day and save the ones I > find > might be useful at some point in the future but have not had occassion to > post > any questions myself until today. What is elm? > -Thanks > From owner-sqr-users@list.iex.net Mon Jul 12 10:59:20 1999 Date: Mon, 12 Jul 1999 06:49:58 PDT From: Rajvirendra Singh Subject: Re: Mailing SQR report from unix Hi there, Try following code. I cut and paste it from working shell script. $4 is subject and $5 is email address. Hope it will help you. uuencode /tmp/$tempname.spf /tmp/$tempname.spf >/tmp/atchmntmsg.txt # # HP # if (-e /usr/bin/mailx) then /usr/bin/mailx -s "$4" $5 From: "Karimundackal, Liz J." >Reply-To: SQR-USERS@list.iex.net >To: Multiple recipients of list SQR-USERS >Subject: Mailing SQR report from unix >Date: Fri, 9 Jul 1999 10:19:59 -0400 > >Hi all, > I am trying to mail the report created by my SQR program from the >same program. > My code is : >let $command = 'uuencode letter.htm letter.htm > letter.uue' >call system using $command #encode_status >let $command = 'mail lkarimundackal@jhancock.com < letter.uue' >call system using $command #mail_status > >My intention is to send the report as an attachment. I tried the uuencode >and the mail command >from the unix prompt and it worked great, but when I do the same commands >from SQR, the >encoded file goes as text, so the mail has a lot of junk as the text. All >the files, including the uuencoded >file is created properly from SQR and both commands have a success return >code. > >Any help will be appreciated. >Thanks in advance, >Liz J Karimundackal >(617) 572-8288 >e-mail : lkarimundackal@jhancock.com > _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From owner-sqr-users@list.iex.net Mon Jul 12 11:15:09 1999 Date: Mon, 12 Jul 1999 10:00:53 -0600 From: "Ackerson, Glenn" Subject: Date Formatting problem corrected by datemath.sqc Hi all, Thanks to those who responded for your useful suggestions. The first one I tried worked like a charm - rather than use the datetime.sqc, one of you suggested using datemath.sqc to convert the date from the yyyy-mm-dd format to the native dd-mon-yy Oracle format. Once I did that, the code worked like a charm. Thanks again for your suggestions! I must confess I was a little rusty in my SQR programming since I've been consumed with release upgrades and tax updates for months - it's almost become a full time job! Regards, Glenn ************************************************** Glenn Ackerson Information Technology Professional III Internet Address: gsacker@is.unco.edu University of Northern Colorado Information Services Carter Hall Greeley, CO 80639 From owner-sqr-users@list.iex.net Mon Jul 12 11:29:32 1999 Date: Mon, 12 Jul 1999 12:24:33 -0400 From: "Johnson, Dan" Subject: Fetching across commits Hi All, We are currently experiencing the Oracle 1555 error, or Snapshot too old: Rollback segment with name xxx too small. We know that this error can occur if you are fetching across commits, can anyone tell me if this is done by SQR as a default or if it must be specified by the programmer. Thanks for any help. Dan Johnson Programmer/Analyst Wright Express Corp From owner-sqr-users@list.iex.net Wed Jul 14 15:07:09 1999 Date: Mon, 12 Jul 1999 21:56:09 +0100 From: Franck Masson Subject: Re: Postscript printing and printing images This is a multi-part message in MIME format. --------------3AC5D21B08CD2094383B8D64 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi, can you send me your postcript lis file to see what are in postcript code. Here is an example of sqr program with logo in postcript. Franck, Debra Benton wrote: > > Hello All, > > You will probably hear from me quite a bit today - I apologize for the > inconvenience. I am having problems printing images and getting the > postscript *.lis file to print the right place on a file. > > Image printing. > I know there have been multiple e-mails regarding image printing, but I am > still having problems. I need to print to a file and then send the *.lis > file to a printer because this company will outsource the printing of their > invoices to a third party printer. I know that I can use a bitmap and send > it directly to my laserjet printer here using -PRINTER:WP. I also know that > because I am using DOS to send my file to the printer, that I cannot use a > bitmap file. I've had the bitmap converted to a *.gif file and an *.eps > file. Using both the LASERJET and POSTSCRIPT printer configurations, I > still receive either a grey box or a box with a line through it. I know > there are also HPGL-FILE and JPEG-FILE types to test. Am I just using the > wrong type of file? If yes, can anyone recommend some SHAREWARE that can > convert a *.bmp/*.gif/*.eps file to one of these formats. I've tried > downloading Adobe and several other shareware files, but their demo copies > do not let you save. > > Postscript printing. > When I change my printer definition from LASERJET to POSTSCRIPT (this made > my French characters work thanks to a a POSTSCRI.STR file from Franck Masson > - they still don't work on the LASERJET definition, although I think I need > to use a symbol-set other than the default OU), I get a printed page that > cuts off the top of my invoice and essentially moves the entire page up > about half way. I assumed that I might have some problems with my page > size/orientation. Here are the paramenters I have: > type = POSTSCRIPT > left-margin=.25 > top-margin=.25 > font=3 ! Font number > font-style=fixed > lines-inch=7 ! Lines per inch > point-size=6 > orientation=portrait ! portrait or landscape > > #define PAGE_MAX_COLS 135 > #define PAGE_MAX_LINES 79 > page-size = 79 135 > > I tried commenting out the top-margin and the page-size to use the > defaults with no luck. > > Any help would be appreciated. I am attaching the eps file, the gif file, > the bitmap file and the postscri.str file. > > Thanks, > Debbie > <> <> <> <> > > ------------------------------------------------------------------------ > > Name: logo.bmp > logo.bmp Type: Image bitmap (image/bmp) > Encoding: base64 > > Name: logo.eps > logo.eps Type: Notepad File (application/postscript) > Encoding: base64 > > Name: logo.gif > logo.gif Type: GIF Image (image/gif) > Encoding: base64 > > Name: postscri.str > postscri.str Type: application/x-unknown-content-type-str_auto_file > Encoding: quoted-printable --------------3AC5D21B08CD2094383B8D64 Content-Type: application/x-unknown-content-type-SQRIBE.Source; name="sqrlogo.sqr" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="sqrlogo.sqr" ISBTUVJMb2dvICBEZW1vbnN0cmF0ZSBTUVIgdjMuMCBpbWFnZSBzdXBwb3J0IA0KISAgICAg ICAgICBUbyBwcmludCB0aGlzIHJlcG9ydCB0byBhbiBIUCwgdXNlIHRoZSBmb2xsb3dpbmc6 DQohICAgICAgICAgIHNxciBzcXJsb2dvIC8gLXByaW50ZXI6aHANCiENCkJlZ2luLVNldHVw DQogRGVjbGFyZS1MYXlvdXQgU1FSTG9nbw0KICBPcmllbnRhdGlvbj1Qb3J0cmFpdA0KICBM ZWZ0LU1hcmdpbj0uOTUgIFRvcC1NYXJnaW49Ljc1DQogIE1heC1MaW5lcz02MiAgICAgTWF4 LUNvbHVtbnM9ODANCiBFbmQtRGVjbGFyZQ0KIERlY2xhcmUtUmVwb3J0IFNRUkxvZ28NCiAg TGF5b3V0PVNRUkxvZ28NCiAgUHJpbnRlci1UeXBlPVBvc3RzY3JpcHQNCiBFbmQtRGVjbGFy ZSANCiBEZWNsYXJlLUltYWdlIGxvZ28NCiAgSW1hZ2UtU2l6ZSA9ICgzMywgNikNCiAgU291 cmNlID0gJ3NxcmliZS5lcHMnDQogIFR5cGUgPSAgRVBTLUZJTEUNCiBFbmQtRGVjbGFyZQ0K RW5kLVNldHVwDQoNCkJlZ2luLVByb2dyYW0NCiBHcmFwaGljICgxLDEsNjYpIEJveCA1OCAy MCAgISBEcmF3IGJveCBhcm91bmQgd2hvbGUgcGFnZS4NCiBBbHRlci1QcmludGVyIEZvbnQ9 NSBQb2ludC1TaXplPTMwDQogUHJpbnQgJ1NRUiBTdXBwb3J0cyBJbWFnZXMhIScgKDMsMTYp DQogUHJpbnQgJ1NRUiBTdXBwb3J0cyBJbWFnZXMhIScgKDU3LDE2KQ0KIEFsdGVyLVByaW50 ZXIgRm9udD01IFBvaW50LVNpemU9MTINCiBQcmludCAnU1FSIG5vdyBTdXBwb3J0cyBFUFMg YW5kIEhQR0wgaW1hZ2VzJyAoNSwyMSkNCiBQcmludCAnKGFuZCBCaXRtYXAgbG9nb3MgZm9y IFdpbmRvd3MpJyAoNiwyNCkNCiBQcmludC1JbWFnZSBsb2dvICgxMCwxMSkNCg0KIFByaW50 ICdIZXJlIGlzIHRoZSBTUVIgcHJvZ3JhbSB0aGF0IHByb2R1Y2VkIHRoaXMgcGFnZTonICgx OCwgMTcpDQogISAgRHJhdyBzaGFkZWQgYm94IHdpdGggdmVydGljYWwgbGluZSB0byBjcmVh dGUgdHdvIGNvbHVtbnMNCiBHcmFwaGljICgyMCwyLDY0KSBCb3ggMzUgMTAgNCAgICEgQm94 IHdpdGggNCBwZXJjZW50IHNoYWRpbmcNCiBHcmFwaGljICgxOSwzMywzNSkgVmVydC1MaW5l IDQNCiBBbHRlci1QcmludGVyIEZvbnQ9NSBQb2ludC1TaXplPTcNCiBPcGVuICdzcXJsb2dv LnNxcicgQXMgMSBGb3ItUmVhZGluZyBSZWNvcmQ9MjAwDQogTGV0ICNMaW5lID0gMjANCiBD b2x1bW5zIDMgMzQNCiBXaGlsZSAxDQogICAgUmVhZCAxIEludG8gJFJlYzoyMDANCiAgICAg IElmICNFbmQtRmlsZQ0KICAgICAgICAgQnJlYWsNCiAgICAgIEVuZC1JZg0KICAgIFByaW50 ICRSZWMgKCNMaW5lLDEpDQogICAgQWRkIDEgVG8gI0xpbmUNCiAgICBJZiAjTGluZSA+IDU0 DQogICAgICAgTmV4dC1jb2x1bW4gDQogICAgICAgTGV0ICNMaW5lID0gMjANCiAgICBFbmQt SWYNCiBFbmQtV2hpbGUNCiBDbG9zZSAxDQpFbmQtUHJvZ3JhbQ0K --------------3AC5D21B08CD2094383B8D64 Content-Type: application/postscript; name="sqribe.eps" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sqribe.eps" !PS-Adobe-3.0 EPSF-3.0 %%Creator: Adobe Illustrator(TM) 3.2 %%For: (Shawn Castronovo) (Jacobs Fulton Design Group) %%Title: (Sqribe logo FINAL PC.eps) %%CreationDate: (1/7/97) (2:54 PM) %%BoundingBox: 103 -225 494 -135 %%DocumentProcessColors: Cyan Magenta Yellow Black %%DocumentSuppliedResources: procset Adobe_packedarray 2.0 0 %%+ procset Adobe_cmykcolor 1.1 0 %%+ procset Adobe_cshow 1.1 0 %%+ procset Adobe_customcolor 1.0 0 %%+ procset Adobe_IllustratorA_AI3 1.0 1 %AI3_ColorUsage: Color %%CMYKCustomColor: 0.91 0.79 1 0 (PANTONE 440 CV) %%+ 0 1 0.56 0.18 (PANTONE 1945 CV) %AI3_TemplateBox: 307.5 -397.5 307.5 -397.5 %AI3_TileBox: 31.5 -762.5 583.5 -32.5 %AI3_DocumentPreview: PC_TIFF %%EndComments %%BeginProlog %%BeginResource: procset Adobe_packedarray 2.0 0 %%Title: (Packed Array Operators) %%Version: 2.0 %%CreationDate: (8/2/90) () %%Copyright: ((C) 1987-1990 Adobe Systems Incorporated All Rights Reserved) userdict /Adobe_packedarray 5 dict dup begin put /initialize { /packedarray where { pop } { Adobe_packedarray begin Adobe_packedarray { dup xcheck { bind } if userdict 3 1 roll put } forall end } ifelse } def /terminate { } def /packedarray { array astore readonly } def /setpacking { pop } def /currentpacking { false } def currentdict readonly pop end %%EndResource Adobe_packedarray /initialize get exec %%BeginResource: procset Adobe_cmykcolor 1.1 0 %%Title: (CMYK Color Operators) %%Version: 1.1 %%CreationDate: (1/23/89) () %%Copyright: ((C) 1987-1990 Adobe Systems Incorporated All Rights Reserved) currentpacking true setpacking userdict /Adobe_cmykcolor 4 dict dup begin put /initialize { /setcmykcolor where { pop } { userdict /Adobe_cmykcolor_vars 2 dict dup begin put /_setrgbcolor /setrgbcolor load def /_currentrgbcolor /currentrgbcolor load def Adobe_cmykcolor begin Adobe_cmykcolor { dup xcheck { bind } if pop pop } forall end end Adobe_cmykcolor begin } ifelse } def /terminate { currentdict Adobe_cmykcolor eq { end } if } def /setcmykcolor { 1 sub 4 1 roll 3 { 3 index add neg dup 0 lt { pop 0 } if 3 1 roll } repeat Adobe_cmykcolor_vars /_setrgbcolor get exec pop } def /currentcmykcolor { Adobe_cmykcolor_vars /_currentrgbcolor get exec 3 { 1 sub neg 3 1 roll } repeat 0 } def currentdict readonly pop end setpacking %%EndResource %%BeginResource: procset Adobe_cshow 1.1 0 %%Title: (cshow Operator) %%Version: 1.1 %%CreationDate: (1/23/89) () %%Copyright: ((C) 1987-1990 Adobe Systems Incorporated All Rights Reserved) currentpacking true setpacking userdict /Adobe_cshow 3 dict dup begin put /initialize { /cshow where { pop } { userdict /Adobe_cshow_vars 1 dict dup begin put /_cshow {} def Adobe_cshow begin Adobe_cshow { dup xcheck { bind } if userdict 3 1 roll put } forall end end } ifelse } def /terminate { } def /cshow { exch Adobe_cshow_vars exch /_cshow exch put { 0 0 Adobe_cshow_vars /_cshow get exec } forall } def currentdict readonly pop end setpacking %%EndResource %%BeginResource: procset Adobe_customcolor 1.0 0 %%Title: (Custom Color Operators) %%Version: 1.0 %%CreationDate: (5/9/88) () %%Copyright: ((C) 1987-1990 Adobe Systems Incorporated All Rights Reserved) currentpacking true setpacking userdict /Adobe_customcolor 5 dict dup begin put /initialize { /setcustomcolor where { pop } { Adobe_customcolor begin Adobe_customcolor { dup xcheck { bind } if pop pop } forall end Adobe_customcolor begin } ifelse } def /terminate { currentdict Adobe_customcolor eq { end } if } def /findcmykcustomcolor { 5 packedarray } def /setcustomcolor { exch aload pop pop 4 { 4 index mul 4 1 roll } repeat 5 -1 roll pop setcmykcolor } def /setoverprint { pop } def currentdict readonly pop end setpacking %%EndResource %%BeginResource: procset Adobe_IllustratorA_AI3 1.1 3 %%Title: (Adobe Illustrator (R) Version 3.0 Abbreviated Prolog) %%Version: 1.1 %%CreationDate: (3/7/1994) () %%Copyright: ((C) 1987-1994 Adobe Systems Incorporated All Rights Reserved) currentpacking true setpacking userdict /Adobe_IllustratorA_AI3 61 dict dup begin put /initialize { userdict /Adobe_IllustratorA_AI3_vars 58 dict dup begin put /_lp /none def /_pf {} def /_ps {} def /_psf {} def /_pss {} def /_pjsf {} def /_pjss {} def /_pola 0 def /_doClip 0 def /cf currentflat def /_tm matrix def /_renderStart [/e0 /r0 /a0 /o0 /e1 /r1 /a1 /i0] def /_renderEnd [null null null null /i1 /i1 /i1 /i1] def /_render -1 def /_rise 0 def /_ax 0 def /_ay 0 def /_cx 0 def /_cy 0 def /_leading [0 0] def /_ctm matrix def /_mtx matrix def /_sp 16#020 def /_hyphen (-) def /_fScl 0 def /_cnt 0 def /_hs 1 def /_nativeEncoding 0 def /_useNativeEncoding 0 def /_tempEncode 0 def /_pntr 0 def /_tDict 2 dict def /_wv 0 def /Tx {} def /Tj {} def /CRender {} def /_AI3_savepage {} def /_gf null def /_cf 4 array def /_if null def /_of false def /_fc {} def /_gs null def /_cs 4 array def /_is null def /_os false def /_sc {} def /_i null def Adobe_IllustratorA_AI3 begin Adobe_IllustratorA_AI3 { dup xcheck { bind } if pop pop } forall end end Adobe_IllustratorA_AI3 begin Adobe_IllustratorA_AI3_vars begin newpath } def /terminate { end end } def /_ null def /ddef { Adobe_IllustratorA_AI3_vars 3 1 roll put } def /xput { dup load dup length exch maxlength eq { dup dup load dup length 2 mul dict copy def } if load begin def end } def /npop { { pop } repeat } def /sw { dup length exch stringwidth exch 5 -1 roll 3 index mul add 4 1 roll 3 1 roll mul add } def /swj { dup 4 1 roll dup length exch stringwidth exch 5 -1 roll 3 index mul add 4 1 roll 3 1 roll mul add 6 2 roll /_cnt 0 ddef {1 index eq {/_cnt _cnt 1 add ddef} if} forall pop exch _cnt mul exch _cnt mul 2 index add 4 1 roll 2 index add 4 1 roll pop pop } def /ss { 4 1 roll { 2 npop (0) exch 2 copy 0 exch put pop gsave false charpath currentpoint 4 index setmatrix stroke grestore moveto 2 copy rmoveto } exch cshow 3 npop } def /jss { 4 1 roll { 2 npop (0) exch 2 copy 0 exch put gsave _sp eq { exch 6 index 6 index 6 index 5 -1 roll widthshow currentpoint } { false charpath currentpoint 4 index setmatrix stroke }ifelse grestore moveto 2 copy rmoveto } exch cshow 6 npop } def /sp { { 2 npop (0) exch 2 copy 0 exch put pop false charpath 2 copy rmoveto } exch cshow 2 npop } def /jsp { { 2 npop (0) exch 2 copy 0 exch put _sp eq { exch 5 index 5 index 5 index 5 -1 roll widthshow } { false charpath }ifelse 2 copy rmoveto } exch cshow 5 npop } def /pl { transform 0.25 sub round 0.25 add exch 0.25 sub round 0.25 add exch itransform } def /setstrokeadjust where { pop true setstrokeadjust /c { curveto } def /C /c load def /v { currentpoint 6 2 roll curveto } def /V /v load def /y { 2 copy curveto } def /Y /y load def /l { lineto } def /L /l load def /m { moveto } def } { /c { pl curveto } def /C /c load def /v { currentpoint 6 2 roll pl curveto } def /V /v load def /y { pl 2 copy curveto } def /Y /y load def /l { pl lineto } def /L /l load def /m { pl moveto } def }ifelse /d { setdash } def /cf {} def /i { dup 0 eq { pop cf } if setflat } def /j { setlinejoin } def /J { setlinecap } def /M { setmiterlimit } def /w { setlinewidth } def /H {} def /h { closepath } def /N { _pola 0 eq { _doClip 1 eq {clip /_doClip 0 ddef} if newpath } { /CRender {N} ddef }ifelse } def /n {N} def /F { _pola 0 eq { _doClip 1 eq { gsave _pf grestore clip newpath /_lp /none ddef _fc /_doClip 0 ddef } { _pf }ifelse } { /CRender {F} ddef }ifelse } def /f { closepath F } def /S { _pola 0 eq { _doClip 1 eq { gsave _ps grestore clip newpath /_lp /none ddef _sc /_doClip 0 ddef } { _ps }ifelse } { /CRender {S} ddef }ifelse } def /s { closepath S } def /B { _pola 0 eq { _doClip 1 eq gsave F grestore { gsave S grestore clip newpath /_lp /none ddef _sc /_doClip 0 ddef } { S }ifelse } { /CRender {B} ddef }ifelse } def /b { closepath B } def /W { /_doClip 1 ddef } def /* { count 0 ne { dup type (stringtype) eq {pop} if } if _pola 0 eq {newpath} if } def /u {} def /U {} def /q { _pola 0 eq {gsave} if } def /Q { _pola 0 eq {grestore} if } def /*u { _pola 1 add /_pola exch ddef } def /*U { _pola 1 sub /_pola exch ddef _pola 0 eq {CRender} if } def /D {pop} def /*w {} def /*W {} def /` { /_i save ddef 6 1 roll 4 npop concat pop userdict begin /showpage {} def 0 setgray 0 setlinecap 1 setlinewidth 0 setlinejoin 10 setmiterlimit [] 0 setdash /setstrokeadjust where {pop false setstrokeadjust} if newpath 0 setgray false setoverprint } def /~ { end _i restore } def /O { 0 ne /_of exch ddef /_lp /none ddef } def /R { 0 ne /_os exch ddef /_lp /none ddef } def /g { /_gf exch ddef /_fc { _lp /fill ne { _of setoverprint _gf setgray /_lp /fill ddef } if } ddef /_pf { _fc fill } ddef /_psf { _fc ashow } ddef /_pjsf { _fc awidthshow } ddef /_lp /none ddef } def /G { /_gs exch ddef /_sc { _lp /stroke ne { _os setoverprint _gs setgray /_lp /stroke ddef } if } ddef /_ps { _sc stroke } ddef /_pss { _sc ss } ddef /_pjss { _sc jss } ddef /_lp /none ddef } def /k { _cf astore pop /_fc { _lp /fill ne { _of setoverprint _cf aload pop setcmykcolor /_lp /fill ddef } if } ddef /_pf { _fc fill } ddef /_psf { _fc ashow } ddef /_pjsf { _fc awidthshow } ddef /_lp /none ddef } def /K { _cs astore pop /_sc { _lp /stroke ne { _os setoverprint _cs aload pop setcmykcolor /_lp /stroke ddef } if } ddef /_ps { _sc stroke } ddef /_pss { _sc ss } ddef /_pjss { _sc jss } ddef /_lp /none ddef } def /x { /_gf exch ddef findcmykcustomcolor /_if exch ddef /_fc { _lp /fill ne { _of setoverprint _if _gf 1 exch sub setcustomcolor /_lp /fill ddef } if } ddef /_pf { _fc fill } ddef /_psf { _fc ashow } ddef /_pjsf { _fc awidthshow } ddef /_lp /none ddef } def /X { /_gs exch ddef findcmykcustomcolor /_is exch ddef /_sc { _lp /stroke ne { _os setoverprint _is _gs 1 exch sub setcustomcolor /_lp /stroke ddef } if } ddef /_ps { _sc stroke } ddef /_pss { _sc ss } ddef /_pjss { _sc jss } ddef /_lp /none ddef } def /A { pop } def currentdict readonly pop end setpacking /annotatepage { } def %%EndResource %%EndProlog %%BeginSetup Adobe_cmykcolor /initialize get exec Adobe_cshow /initialize get exec Adobe_customcolor /initialize get exec Adobe_IllustratorA_AI3 /initialize get exec %%EndSetup 0 A u *u 0 O 0.24 1 0.7 0.13 k 0 i 0 J 0 j 1 w 4 M []0 d %AI3_Note: 0 D 224.063 -219.8723 m 222.6115 -220.2563 221.4321 -220.4388 219.89 -220.4483 c 206.5 -220.5311 205.7105 -211.8314 194.0985 -207.0317 c 176.8618 -205.7838 164.0705 -193.5927 164.0705 -176.6979 c 164.0705 -158.3632 178.3133 -144.4442 196.9107 -144.4442 c 214.4195 -144.4442 229.1159 -156.4434 229.1159 -174.3941 c 229.1159 -189.273 219.7719 -202.328 204.8939 -206.1678 c 204.8939 -206.3597 L 214.625 -210.2811 214.2654 -217.5685 225.5145 -217.8564 C 224.063 -219.8723 l f 1 D 194.915 -146.8441 m 178.9484 -146.8441 172.598 -162.5869 172.598 -174.1061 c 172.598 -192.0568 184.1192 -204.6319 198.7251 -204.6319 c 213.5123 -204.6319 220.5884 -190.9049 220.5884 -177.2739 c 220.5884 -159.4192 209.8835 -146.8441 194.915 -146.8441 c f *U *u 0 D 264.9299 -196.5685 m 264.9299 -202.328 267.1071 -203.7679 272.1874 -203.7679 c 274.2739 -203.7679 L 274.2739 -205.5918 L 248.6005 -205.5918 L 248.6005 -203.7679 L 250.1427 -203.7679 L 255.4951 -203.7679 257.4003 -202.232 257.4003 -195.8005 c 257.4003 -155.3874 L 257.4003 -149.4359 255.858 -147.708 250.5963 -147.708 c 248.6005 -147.708 L 248.6005 -145.8841 L 250.7778 -145.8841 256.3116 -145.5002 260.0311 -145.3082 c 263.7505 -145.1162 265.5649 -145.0202 271.4617 -145.0202 c 288.2448 -145.0202 295.7744 -152.3157 295.7744 -162.107 c 295.7744 -169.3064 291.1478 -175.354 283.7087 -177.6578 c 287.0654 -180.4416 289.7869 -183.1294 294.0506 -187.6411 c 301.2175 -195.2246 L 306.5699 -200.8881 312.1039 -204.4399 319.0891 -204.9199 c 319.0891 -206.6477 L 303.2133 -207.4157 299.131 -203.7679 291.0571 -195.2246 c 285.0695 -188.889 L 281.0778 -184.6653 277.9027 -181.8815 275.7254 -180.3456 c 273.4574 -180.4416 272.006 -180.5376 269.5566 -180.5376 c 267.5607 -180.5376 266.3814 -180.4416 264.9299 -180.3456 C 264.9299 -196.5685 l f 1 D 264.9299 -178.5218 m 267.1071 -178.8097 268.468 -178.7138 270.5545 -178.7138 c 280.6243 -178.7138 287.2468 -174.2021 287.2468 -162.6829 c 287.2468 -153.7556 283.4366 -146.8441 269.4659 -146.8441 c 267.7422 -146.8441 266.5629 -146.8441 264.9299 -147.036 C 264.9299 -178.5218 l f *U *u 0 D 349.3616 -167.3333 m 346.6667 -168.8333 346.2492 -169.7168 v 345.8279 -170.6083 345.8036 -171.7168 y 345.8036 -198.2963 l 345.8036 -201.6561 347.5272 -203.7679 352.3354 -203.7679 c 352.3354 -205.5918 L 331.2949 -205.5918 L 331.2949 -203.7679 L 336.8289 -203.7679 338.8247 -201.8481 338.8247 -196.7604 c 338.8247 -177.4658 L 338.8247 -173.7221 338.3712 -173.2421 336.0124 -172.7622 c 331.7485 -171.8982 L 331.7485 -170.3624 L 343.3242 -166.7168 L 349.3616 -164.2793 L 349.3616 -167.3333 l f *U *u 382.0615 -156.0594 m 382.0615 -150.5878 381.4266 -147.708 375.0761 -147.708 c 371.9009 -147.708 L 371.9009 -145.8841 L 374.4411 -145.7881 380.7008 -145.4042 383.3316 -145.3082 c 388.3211 -145.1162 395.2158 -145.0202 396.9394 -145.0202 c 404.9228 -145.0202 411.908 -146.2681 415.1739 -148.7639 c 418.8934 -151.5477 420.7078 -154.8115 420.7078 -159.4192 c 420.7078 -164.8908 416.4441 -169.9784 410.3659 -171.1303 c 410.3659 -171.3223 L 418.8934 -174.0101 423.883 -179.8657 423.883 -187.3531 c 423.883 -194.9366 418.8934 -205.5918 404.2877 -205.5918 c 371.0845 -205.5918 L 371.0845 -203.7679 L 373.171 -203.7679 L 380.61 -203.7679 382.0615 -201.9441 382.0615 -195.8965 C 382.0615 -156.0594 l f 1 D 389.5911 -170.8423 m 399.4797 -170.8423 L 408.1885 -170.8423 412.5431 -167.1946 412.5431 -159.7071 c 412.5431 -152.9876 408.7328 -146.8441 397.5745 -146.8441 c 395.5787 -146.8441 391.8591 -147.036 389.5911 -147.132 C 389.5911 -170.8423 l f 389.5911 -193.1127 m 389.5911 -200.4082 392.3128 -203 399.9333 -203 c 411.908 -203 415.3553 -195.1286 415.3553 -187.6411 c 415.3553 -180.2496 410.003 -172.6662 399.3888 -172.6662 c 389.5911 -172.6662 L 389.5911 -193.1127 l f *U *u 0 D 484.7172 -183.9934 m 482.9935 -183.9934 L 482.2678 -177.1779 480.5441 -176.4099 476.8246 -176.4099 c 461.4932 -176.4099 L 461.4932 -196.8564 L 461.4932 -201.2721 463.0353 -202.1361 466.392 -202.1361 c 480.3628 -202.1361 L 486.713 -202.1361 488.6182 -199.5442 490.8861 -191.2888 c 492.519 -191.2888 L 491.0674 -205.5918 L 442.8957 -205.5918 L 442.8957 -203.7679 L 445.4359 -203.7679 L 452.6933 -203.7679 453.9634 -201.6561 453.9634 -195.8965 c 453.9634 -155.3874 L 453.9634 -150.0118 452.784 -147.708 446.706 -147.708 c 444.7101 -147.708 L 444.7101 -145.8841 L 488.2553 -145.8841 L 488.9811 -159.2272 L 487.348 -159.2272 L 486.1688 -151.0678 483.9007 -149.3399 480.6348 -149.3399 c 461.4932 -149.3399 L 461.4932 -172.9542 L 477.7318 -172.9542 L 480.9977 -172.9542 482.54 -171.3223 482.9935 -165.7547 c 484.7172 -165.7547 L 484.7172 -183.9934 l f *U u 0 0.15 0 0.55 k 340.6623 -144.2507 m 340.6623 -141.1703 L 334.714 -143.9695 L 334.714 -147.0498 L 340.6623 -144.2507 L f 343.9797 -145.7832 m 343.9797 -142.7028 L 338.0316 -145.502 L 338.0316 -148.5823 L 343.9797 -145.7832 L f 342.3885 -152.7717 m 342.3885 -149.6913 L 336.4403 -152.4905 L 336.4403 -155.5708 L 342.3885 -152.7717 L f 337.9589 -148.6248 m 337.9589 -145.5445 L 332.0106 -148.3436 L 332.0106 -151.424 L 337.9589 -148.6248 L f 350.4346 -139.5624 m 350.4346 -136.4821 L 345.9026 -138.7501 L 345.9026 -141.8305 L 350.4346 -139.5624 L f 347.9541 -146.8495 m 347.9541 -143.7692 L 343.4221 -146.0372 L 343.4221 -149.1175 L 347.9541 -146.8495 L f 358.876 -138.4835 m 358.876 -135.4032 L 356.1143 -136.7861 L 356.1143 -139.8664 L 358.876 -138.4835 L f 345.4022 -154.6671 m 345.4022 -151.5868 L 342.6405 -152.9696 L 342.6405 -156.05 L 345.4022 -154.6671 L f 339.4023 -141.7087 m 339.4023 -138.6284 L 336.6405 -140.0113 L 336.6405 -143.0916 L 339.4023 -141.7087 L f 319.443 -157.5348 m 319.443 -154.4545 L 316.6813 -155.8374 L 316.6813 -158.9177 L 319.443 -157.5348 L f 330.4022 -155.1255 m 330.4022 -152.0451 L 327.6405 -153.428 L 327.6405 -156.5083 L 330.4022 -155.1255 L f 353.2023 -141.1671 m 353.2023 -138.0868 L 350.4405 -139.4696 L 350.4405 -142.55 L 353.2023 -141.1671 L f 331.7666 -144.5162 m 331.7666 -141.4358 L 327.2346 -143.7039 L 327.2346 -146.7842 L 331.7666 -144.5162 L f 339.4958 -150.9328 m 339.4958 -147.8525 L 334.9638 -150.1206 L 334.9638 -153.2009 L 339.4958 -150.9328 L f 327.6759 -153.3607 m 327.6759 -150.2804 L 323.1439 -152.5484 L 323.1439 -155.6288 L 327.6759 -153.3607 L f U *u 0.24 1 0.7 0.13 k 106.0507 -192.5714 m 107.9558 -201.1147 114.3061 -206.1064 121.3821 -206.1064 c 127.4603 -206.1064 133.9014 -202.3627 133.9014 -194.7791 c 133.9014 -180.9562 104.7806 -176.7325 104.7806 -159.9337 c 104.7806 -151.9663 111.6751 -146.0147 120.9285 -146.0147 c 128.549 -146.0147 130.0913 -148.4146 133.2663 -148.4146 c 133.9921 -148.4146 134.355 -148.2226 134.8993 -147.4545 c 136.3507 -147.4545 L 137.8931 -159.6456 L 136.3507 -159.6456 L 133.8106 -152.7342 128.0046 -148.3185 121.745 -148.3185 c 115.7575 -148.3185 111.5846 -151.9663 111.5846 -157.3418 c 111.5846 -170.9729 140.7053 -174.6207 140.7053 -192.2834 c 140.7053 -201.6906 132.8128 -208.6982 122.1986 -208.6982 c 117.2091 -208.6982 110.8588 -206.1064 109.5888 -206.1064 c 108.7723 -206.1064 108.1372 -206.5862 107.7743 -207.1623 c 106.2322 -207.1623 L 104.327 -192.5714 L 106.0507 -192.5714 l f *U *u 0 g 248.6586 -215.6773 m 257.7719 -215.6773 L 257.7719 -217.3543 L 254.3658 -217.3543 L 254.3658 -224.8556 L 252.0647 -224.8556 L 252.0647 -217.3543 L 248.6586 -217.3543 L 248.6586 -215.6773 l f *U *u 269.6114 -215.6773 m 278.1657 -215.6773 L 278.1657 -217.3283 L 271.9125 -217.3283 L 271.9125 -219.3954 L 277.9577 -219.3954 L 277.9577 -221.0205 L 271.9125 -221.0205 L 271.9125 -223.2175 L 278.4257 -223.2175 L 278.4257 -224.8556 L 269.6114 -224.8556 L 269.6114 -215.6773 l f *U *u 301.1237 -221.7355 m 300.9547 -222.3075 300.7467 -222.9705 299.9277 -223.7246 c 299.1866 -224.4006 297.9646 -225.1676 295.6245 -225.1676 c 292.3614 -225.1676 290.0993 -223.4645 290.0993 -220.2534 c 290.0993 -216.7953 292.8554 -215.3912 295.7545 -215.3912 c 296.8076 -215.3912 299.8237 -215.6253 301.0197 -218.2514 c 298.4976 -218.5634 L 298.2506 -218.1734 297.5356 -217.0813 295.7545 -217.0813 c 293.6744 -217.0813 292.4914 -218.5244 292.4914 -220.2794 c 292.4914 -222.2815 294.0644 -223.4776 295.8065 -223.4776 c 297.7956 -223.4776 298.4066 -222.3075 298.7056 -221.7485 C 301.1237 -221.7355 l f *U *u 313.1091 -215.6773 m 315.4102 -215.6773 L 315.4102 -219.2134 L 320.9614 -219.2134 L 320.9614 -215.6773 L 323.2625 -215.6773 L 323.2625 -224.8556 L 320.9614 -224.8556 L 320.9614 -220.9165 L 315.4102 -220.9165 L 315.4102 -224.8556 L 313.1091 -224.8556 L 313.1091 -215.6773 l f *U *u 336.7428 -215.6773 m 339.0309 -215.6773 L 343.5291 -220.7864 L 344.0751 -221.4235 344.1791 -221.5535 344.7511 -222.2685 c 344.6731 -221.3975 344.6731 -221.1635 344.6601 -220.3704 c 344.6601 -215.6773 L 346.8572 -215.6773 L 346.8572 -224.8556 L 344.5821 -224.8556 L 340.032 -219.6814 L 339.5509 -219.1224 339.3559 -218.8884 338.8489 -218.2384 c 338.9139 -218.9404 338.9139 -219.0964 338.9269 -219.7984 c 338.9269 -224.8556 L 336.7428 -224.8556 L 336.7428 -215.6773 l f *U *u 368.9179 -217.1723 m 369.295 -217.6273 369.906 -218.6414 369.906 -220.1754 c 369.906 -223.1005 368.0079 -225.1546 364.3028 -225.1546 c 360.5976 -225.1546 358.6346 -223.1395 358.6346 -220.2794 c 358.6346 -217.1203 360.8966 -215.5213 363.9128 -215.3912 c 365.7198 -215.3132 367.7739 -215.7813 368.9179 -217.1723 c f 1 D 361.0007 -220.3314 m 361.0007 -221.4495 361.4167 -222.0345 361.5857 -222.2555 c 361.8067 -222.5675 362.4827 -223.5166 364.2638 -223.5166 c 366.4089 -223.5166 367.5529 -222.0605 367.5529 -220.2924 c 367.5529 -218.2384 366.0058 -216.9773 364.1728 -217.0423 c 362.6387 -217.0943 361.0007 -218.1083 361.0007 -220.3314 c f *U *u 0 D 382.4344 -215.6773 m 384.7355 -215.6773 L 384.7355 -223.1655 L 389.8316 -223.1655 L 389.8316 -224.8556 L 382.4344 -224.8556 L 382.4344 -215.6773 l f *U *u 411.0505 -217.1723 m 411.4275 -217.6273 412.0386 -218.6414 412.0386 -220.1754 c 412.0386 -223.1005 410.1405 -225.1546 406.4353 -225.1546 c 402.7302 -225.1546 400.7671 -223.1395 400.7671 -220.2794 c 400.7671 -217.1203 403.0292 -215.5213 406.0453 -215.3912 c 407.8524 -215.3132 409.9065 -215.7813 411.0505 -217.1723 c f 1 D 403.1332 -220.3314 m 403.1332 -221.4495 403.5492 -222.0345 403.7182 -222.2555 c 403.9393 -222.5675 404.6153 -223.5166 406.3963 -223.5166 c 408.5414 -223.5166 409.6855 -222.0605 409.6855 -220.2924 c 409.6855 -218.2384 408.1384 -216.9773 406.3053 -217.0423 c 404.7713 -217.0943 403.1332 -218.1083 403.1332 -220.3314 c f *U *u 0 D 432.6663 -223.8026 m 431.6783 -224.7646 430.2612 -225.1286 428.8702 -225.1286 c 424.528 -225.1286 423.332 -222.4245 423.332 -220.2274 c 423.332 -219.0314 423.761 -217.8743 424.58 -216.9903 c 426.1011 -215.3652 428.4801 -215.3652 429.1952 -215.3652 c 430.0922 -215.3652 431.5353 -215.4692 432.7963 -216.2363 c 433.7973 -216.8603 434.1874 -217.5623 434.4214 -217.9783 c 431.8863 -218.3294 L 431.5093 -217.8743 430.8462 -217.0683 429.1042 -217.0683 c 427.1411 -217.0683 425.698 -218.2124 425.698 -220.2534 c 425.698 -222.0475 426.9331 -223.4515 429.1692 -223.4515 c 430.2612 -223.4515 431.1712 -223.1005 431.7433 -222.6455 c 432.2893 -222.2165 432.3933 -221.8525 432.4973 -221.5925 c 429.4812 -221.5925 L 429.4812 -219.9414 L 434.4214 -219.9414 L 434.4214 -224.8556 L 432.6663 -224.8556 L 432.6663 -223.8026 l f *U *u 447.4177 -215.6773 m 449.7188 -215.6773 L 449.7188 -224.8556 L 447.4177 -224.8556 L 447.4177 -215.6773 l f *U *u 462.9104 -215.6773 m 471.4648 -215.6773 L 471.4648 -217.3283 L 465.2115 -217.3283 L 465.2115 -219.3954 L 471.2568 -219.3954 L 471.2568 -221.0205 L 465.2115 -221.0205 L 465.2115 -223.2175 L 471.7248 -223.2175 L 471.7248 -224.8556 L 462.9104 -224.8556 L 462.9104 -215.6773 l f *U *u 484.1784 -222.0085 m 484.6984 -223.1135 486.0114 -223.4515 487.2595 -223.4515 c 487.8185 -223.4515 489.5736 -223.3605 489.5736 -222.2425 c 489.5736 -221.5795 488.9365 -221.4235 488.4425 -221.3325 c 488.0655 -221.2545 486.1804 -220.9685 485.7514 -220.8905 c 484.9064 -220.7344 482.7743 -220.3314 482.7743 -218.2514 c 482.7743 -217.7963 482.9043 -217.3283 483.1383 -216.9513 c 483.9054 -215.7163 485.5954 -215.3912 487.0515 -215.3912 c 488.3905 -215.3912 489.4176 -215.5863 490.3666 -216.1063 c 491.3026 -216.6133 491.7057 -217.2893 491.8877 -217.5883 c 489.7036 -218.1343 L 489.6256 -217.9913 489.4436 -217.6533 488.8975 -217.3803 c 488.2865 -217.0813 487.4935 -217.0293 487.0515 -217.0293 c 486.0374 -217.0293 484.9974 -217.2243 484.9974 -218.0953 c 484.9974 -218.6934 485.5304 -218.8494 486.2194 -219.0054 c 486.5965 -219.0834 488.4685 -219.3954 488.8975 -219.4864 c 489.9636 -219.6814 491.7707 -220.0714 491.7707 -222.0865 c 491.7707 -225.0376 488.2605 -225.1416 487.1035 -225.1416 c 485.5954 -225.1416 483.2683 -224.8816 482.0853 -222.5545 C 484.1784 -222.0085 l f *U U -4012.5 -144 m 4627.5 -144 L (N) * -4012.5 -395.5 m 4627.5 -395.5 L (N) * -4012.5 -647.5 m 4627.5 -647.5 L (N) * %%PageTrailer gsave annotatepage grestore %%Trailer Adobe_IllustratorA_AI3 /terminate get exec Adobe_customcolor /terminate get exec Adobe_cshow /terminate get exec Adobe_cmykcolor /terminate get exec Adobe_packedarray /terminate get exec %%EOF --------------3AC5D21B08CD2094383B8D64-- From owner-sqr-users@list.iex.net Mon Jul 12 18:03:58 1999 Date: Mon, 12 Jul 1999 17:49:32 -0500 From: Zubin Shroff Subject: SQR command to distinguish alpha characters from aplha-numer Is there an SQR command that can be used to interrogate a field and determine whether all characters are alphabets or alpha-numeric? e.g. Given 2 field values of 'JOB' and 'JOB9', we need to determine that JOB is alpha-only and JOB9 is alpha-numeric. Just wondering if there is an easier way than to read each character and look for the first non-alpha character From owner-sqr-users@list.iex.net Tue Jul 13 00:08:16 1999 Date: Tue, 13 Jul 1999 16:55:19 +1200 From: "Wallach, Jarod" Subject: Image printing This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BECCEB.E8949B5A Content-Type: text/plain; charset="iso-8859-1" I know this type of question is asked alot and I have searched the archives for an answer but... is it possible to print a logo without using one of the -printer flags. the situation is, one of our customers is using object fax to send their purchase orders out to vendors. when this runs as part of this the company logo is placed in the top left hand corner, this works fine when printed to a printer using the -printer:wp switch, ie print to file c:\temp\ -printer:wp. when the report is ran to a printer, \\servername\printer share name the logo does not print correctly. can any one help ???? Jarod Wallach kpmg Enabling Technologies e-mail jwallach@kpmg.co.nz Consultant, KPMG 135 Victoria Street P.O. Box 996 KPMG Wellington Phone +64 4 3828800 x8886 New Zealand Fax +64 4 8021221 Disclaimer: The information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Internet electronic mail message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Internet electronic mail message are subject to the terms and conditions expressed in the governing KPMG client engagement letter ------_=_NextPart_000_01BECCEB.E8949B5A Content-Type: application/octet-stream; name="Jarod Wallach (E-mail).vcf" Content-Disposition: attachment; filename="Jarod Wallach (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Wallach;Jarod FN:Jarod Wallach (E-mail) ORG:KPMG New Zealand;Enabling Technologies TITLE:Consultant TEL;WORK;VOICE:+64 (4) 382 8800 TEL;WORK;FAX:+64 (4) 802 1221 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;KPMG Centre=0D=0A135 Victoria Street=0D=0A(PO Box 996);Wellington;;;New Ze= aland LABEL;WORK;ENCODING=QUOTED-PRINTABLE:KPMG Centre=0D=0A135 Victoria Street=0D=0A(PO Box 996)=0D=0AWellington=0D= =0ANew Zealand EMAIL;PREF;INTERNET:jwallach@kpmg.co.nz REV:19990505T035936Z END:VCARD ------_=_NextPart_000_01BECCEB.E8949B5A-- From owner-sqr-users@list.iex.net Tue Jul 13 00:22:38 1999 Date: Tue, 13 Jul 1999 10:44:02 +0530 From: Shankar Subject: Re: Fetching across commits Dan According to my view it is purely an ORACLE Error , If You are running Transaction , which is Not Commited For e-g In one end you are Updating a Table with huge data , and in other end you are selecting the Data of the same Table, then the Rollback Segment should be capable of holding both the Values ( Records before Updation & Records before selection ) being the case the Selection which is after the Updati So in that case you can overcome the Problem in both ways : 1) Increase the size of the Rollback Segment , and Set the Particular RS to the Transaction. 2) Commit the Changes immed.. Thanks "Johnson, Dan" wrote: > Hi All, > We are currently experiencing the Oracle 1555 error, or Snapshot too > old: Rollback segment with name xxx too small. We know that this error can > occur if you are fetching across commits, can anyone tell me if this is done > by SQR as a default or if it must be specified by the programmer. > > Thanks for any help. > Dan Johnson > Programmer/Analyst > Wright Express Corp From owner-sqr-users@list.iex.net Tue Jul 13 00:45:17 1999 Date: Tue, 13 Jul 1999 17:19:52 +1200 From: "Wallach, Jarod" Subject: image print This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BECCEF.A4895B7C Content-Type: text/plain; charset="iso-8859-1" following on my last e-mail can anyone explain how or what the -printer:wp actually does with respect to converting bitmaps to a printable format ? Jarod Wallach kpmg Enabling Technologies e-mail jwallach@kpmg.co.nz Consultant, KPMG 135 Victoria Street P.O. Box 996 KPMG Wellington Phone +64 4 3828800 x8886 New Zealand Fax +64 4 8021221 Disclaimer: The information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Internet electronic mail message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Internet electronic mail message are subject to the terms and conditions expressed in the governing KPMG client engagement letter ------_=_NextPart_000_01BECCEF.A4895B7C Content-Type: application/octet-stream; name="Jarod Wallach (E-mail).vcf" Content-Disposition: attachment; filename="Jarod Wallach (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Wallach;Jarod FN:Jarod Wallach (E-mail) ORG:KPMG New Zealand;Enabling Technologies TITLE:Consultant TEL;WORK;VOICE:+64 (4) 382 8800 TEL;WORK;FAX:+64 (4) 802 1221 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;KPMG Centre=0D=0A135 Victoria Street=0D=0A(PO Box 996);Wellington;;;New Ze= aland LABEL;WORK;ENCODING=QUOTED-PRINTABLE:KPMG Centre=0D=0A135 Victoria Street=0D=0A(PO Box 996)=0D=0AWellington=0D= =0ANew Zealand EMAIL;PREF;INTERNET:jwallach@kpmg.co.nz REV:19990505T035936Z END:VCARD ------_=_NextPart_000_01BECCEF.A4895B7C-- From owner-sqr-users@list.iex.net Tue Jul 13 06:58:49 1999 Date: Tue, 13 Jul 1999 06:48:01 -0500 From: "Wendel, Robbi" Subject: Re: Image printing This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BECD25.8F6CF39E Content-Type: text/plain; charset="ISO-8859-1" Going from memory here, so you may need to do a little more research..... You can use the PRINT-IMAGE command once you have defined the image in a DECLARE-IMAGE command. ex. Declare-Image MYLOGO type = bmp-file image-size = (40,5) !this is height & width of your desired print size source = 'c:\mylogo.bmp' End-Declare ..... ..... ..... Print-Image MYLOGO (+1,1) !these coordinates are your normal print coordinates The above DECLARE statement goes in your Set-Up section. The Print-Image can go in any section. The only caution I recall is any print commands following the Print-Image you need to adjust for the image size in your print command. The print coordinates for the logo do not actually move your print cursor down the page after the image...it actually still resides at what ever position it was in before you printed your image. Hope this helps some, Robbi Anne Wendel Systems & Computer Technology Corp. Programmer Analyst (615) 747 - 3078 -----Original Message----- From: Wallach, Jarod [mailto:JWallach@KPMG.CO.NZ] Sent: Monday, July 12, 1999 11:55 PM To: Multiple recipients of list SQR-USERS Subject: Image printing I know this type of question is asked alot and I have searched the archives for an answer but... is it possible to print a logo without using one of the -printer flags. the situation is, one of our customers is using object fax to send their purchase orders out to vendors. when this runs as part of this the company logo is placed in the top left hand corner, this works fine when printed to a printer using the -printer:wp switch, ie print to file c:\temp\ -printer:wp. when the report is ran to a printer, \\servername\printer share name the logo does not print correctly. can any one help ???? Jarod Wallach kpmg Enabling Technologies e-mail jwallach@kpmg.co.nz Consultant, KPMG 135 Victoria Street P.O. Box 996 KPMG Wellington Phone +64 4 3828800 x8886 New Zealand Fax +64 4 8021221 Disclaimer: The information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Internet electronic mail message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Internet electronic mail message are subject to the terms and conditions expressed in the governing KPMG client engagement letter ------_=_NextPart_001_01BECD25.8F6CF39E Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Image printing

Going from memory here, so you may need to do a = little more research.....
You can use the PRINT-IMAGE command once you have = defined the image in a DECLARE-IMAGE command.

ex. Declare-Image MYLOGO
        type =3D = bmp-file
        image-size =3D (40,5)  !this is height & width of = your desired print size
        source = =3D 'c:\mylogo.bmp'
    End-Declare
 .....
 .....
 .....
Print-Image MYLOGO (+1,1)  !these coordinates = are your normal print coordinates

The above DECLARE statement goes in your Set-Up = section.  The Print-Image can go in any section. The only caution = I recall is any print commands following the Print-Image you need to = adjust for the image size in your print command. The print coordinates = for the logo do not actually move your print cursor down the page after = the image...it actually still resides at what ever position it was in = before you printed your image.

Hope this helps some,

Robbi Anne Wendel
Systems & Computer Technology Corp.
Programmer Analyst
(615) 747 - 3078

-----Original Message-----
From: Wallach, Jarod [mailto:JWallach@KPMG.CO.NZ]
Sent: Monday, July 12, 1999 11:55 PM
To: Multiple recipients of list SQR-USERS
Subject: Image printing


        I know = this type of question is asked alot and I have searched the
archives for an answer but...

        is it = possible to print a logo without using one of the -printer
flags.

        the = situation is, one of our customers is using object fax to send
their purchase orders out to vendors. when this runs = as part of this the
company logo is placed in the top left hand corner, = this works fine when
printed to a printer using the -printer:wp switch, = ie print to file c:\temp\
-printer:wp. when the report is ran to a printer, = \\servername\printer
<file://\\servername\printer>  share name = the logo does not print correctly.

        can any = one help ????

        Jarod = Wallach
kpmg
Enabling Technologies
e-mail jwallach@kpmg.co.nz
Consultant, KPMG
135 Victoria Street
P.O. Box 996
KPMG Wellington  Phone  +64 4 3828800 = x8886
New Zealand       = Fax         +64 4 = 8021221

        = Disclaimer:

The information in this electronic mail message is = confidential and may be
legally privileged.  It is intended solely for = the addressee.  Access to
this Internet electronic mail message by anyone else = is unauthorised.  If
you are not the intended recipient, any disclosure, = copying, distribution or
any action taken or omitted to be taken in reliance = on it is prohibited and
may be unlawful. When addressed to our clients any = opinions or advice
contained in this Internet electronic mail message = are subject to the terms
and conditions expressed in the governing KPMG = client engagement letter

------_=_NextPart_001_01BECD25.8F6CF39E-- From owner-sqr-users@list.iex.net Tue Jul 13 08:27:15 1999 Date: Tue, 13 Jul 1999 08:15:32 -0500 From: Mike Olson Subject: Re: SQR command to distinguish alpha characters from aplha-numer Here is one way you could do it: if translate($string1, '0123456789', '') <> $string1 show 'string1 is alpha-numeric' end-if > -----Original Message----- > From: Zubin Shroff [SMTP:zshroff@DTTUS.COM] > Sent: Monday, July 12, 1999 5:50 PM > To: Multiple recipients of list SQR-USERS > Subject: SQR command to distinguish alpha characters from > aplha-numer > > Is there an SQR command that can be used to interrogate a field > and > determine whether all characters are alphabets or alpha-numeric? > > e.g. Given 2 field values of 'JOB' and 'JOB9', we need to > determine > that JOB is alpha-only and JOB9 is alpha-numeric. > > Just wondering if there is an easier way than to read each > character > and look for the first non-alpha character From owner-sqr-users@list.iex.net Tue Jul 13 08:58:07 1999 Date: Tue, 13 Jul 1999 09:27:02 -0400 From: Krisjanis Gale Subject: Re: SQR command to distinguish alpha characters from aplha-numer you could use the 'instr' function... it returns the numeric position of a substring y in string x, and returns 0 if not found. hence... let $S= let #i=0 let #alpha=1 while #i<10 and #alpha=1 if instr($S,to_char(#i),1)<>0 let #alpha=0 end-while of course this could be slower than just searching through the string for the first numeric character. that would look like this: let $S= let #i=0 let #alpha=1 while #i='0' and $c<='9' let #alpha=0 end-if end-while (kris)janis p. gale hrsd - federal reserve bank of new york x8163 >>> Zubin Shroff Monday, July 12, 1999 6:49:32 PM >>> Is there an SQR command that can be used to interrogate a field and determine whether all characters are alphabets or alpha-numeric? e.g. Given 2 field values of 'JOB' and 'JOB9', we need to determine that JOB is alpha-only and JOB9 is alpha-numeric. Just wondering if there is an easier way than to read each character and look for the first non-alpha character From owner-sqr-users@list.iex.net Tue Jul 13 10:04:49 1999 Date: Tue, 13 Jul 1999 10:30:20 -0300 From: =?iso-8859-1?Q?Juan_Jos=E9_Breuer_Moreno?= Subject: Re: SQR command to distinguish alpha characters from aplha-numer Perhaps a fast one could use the translate to change de 0123456789 to ########## and the compare the old value with the new one. If there are equal then it's alpha only. Let $test = translate($string, '01234567890', '##########') If $test = $string ! Alpha else ! Alphanumeric or numeric. End-if ----- Original Message ----- From: Zubin Shroff To: Multiple recipients of list SQR-USERS Sent: Monday, July 12, 1999 7:49 PM Subject: SQR command to distinguish alpha characters from aplha-numer > Is there an SQR command that can be used to interrogate a field and > determine whether all characters are alphabets or alpha-numeric? > > e.g. Given 2 field values of 'JOB' and 'JOB9', we need to determine > that JOB is alpha-only and JOB9 is alpha-numeric. > > Just wondering if there is an easier way than to read each character > and look for the first non-alpha character > From owner-sqr-users@list.iex.net Tue Jul 13 11:25:06 1999 Date: Tue, 13 Jul 1999 09:07:45 PDT From: Parijat Sahai Subject: Re: Image printing It depends on the OS you are on. The -Printer flag does not work for Windows 95 and SQR v3. It does, however, work for Windows NT 4.0 or SQR v4 with Windows 95 (at least it's supposed to, going by Nathan's document in SQRUG archives). At my site, we were required to print a logo from the client's machine which had Windows 95. We decided to put the logo in a Printer cartridge and call an escape sequence to print the image. It prints dandy! I can give you more information about escape sequence later if you'd like (unless you already know about it). But then, you should print directly to the printer. Mail me if you need more info. Parijat. -----Original Message----- From: Wallach, Jarod [mailto:JWallach@KPMG.CO.NZ] Sent: Monday, July 12, 1999 11:55 PM To: Multiple recipients of list SQR-USERS Subject: Image printing I know this type of question is asked alot and I have searched the archives for an answer but... is it possible to print a logo without using one of the -printer flags. the situation is, one of our customers is using object fax to send their purchase orders out to vendors. when this runs as part of this the company logo is placed in the top left hand corner, this works fine when printed to a printer using the -printer:wp switch, ie print to file c:\temp\ -printer:wp. when the report is ran to a printer, \\servername\printer share name the logo does not print correctly. can any one help ???? Jarod Wallach kpmg Enabling Technologies e-mail jwallach@kpmg.co.nz Consultant, KPMG 135 Victoria Street P.O. Box 996 KPMG Wellington Phone +64 4 3828800 x8886 New Zealand Fax +64 4 8021221 Disclaimer: The information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Internet electronic mail message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Internet electronic mail message are subject to the terms and conditions expressed in the governing KPMG client engagement letter _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From owner-sqr-users@list.iex.net Tue Jul 13 11:42:37 1999 Date: Tue, 13 Jul 1999 11:24:59 -0500 From: "Ross, Steven" Subject: Re: image print This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BECD4C.4482F316 Content-Type: text/plain; charset="iso-8859-1" Jarod, SQR seems to print based on what type of printer you're using, i.e., HP, lineprinter, etc. This also applies to graphics. So, and EPS graphic will only print correctly when you're using a postscript printer, and a BMP graphic will only print to a Windows printer. When you specify to print to a file: "c:\temp -PRINTER::WP", what you're saying is, "redirect the output file of this SQR to my default Windows printer". I do not think there is another way to specify a "Windows printer" in SQR. HTH, Steven Ross Programmer/Analyst sross@kcm.org -----Original Message----- From: Wallach, Jarod [mailto:JWallach@KPMG.CO.NZ] Sent: Tuesday, July 13, 1999 12:20 AM To: Multiple recipients of list SQR-USERS Subject: image print following on my last e-mail can anyone explain how or what the -printer:wp actually does with respect to converting bitmaps to a printable format ? Jarod Wallach kpmg Enabling Technologies e-mail jwallach@kpmg.co.nz Consultant, KPMG 135 Victoria Street P.O. Box 996 KPMG Wellington Phone +64 4 3828800 x8886 New Zealand Fax +64 4 8021221 Disclaimer: The information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Internet electronic mail message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Internet electronic mail message are subject to the terms and conditions expressed in the governing KPMG client engagement letter ------_=_NextPart_001_01BECD4C.4482F316 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: image print

Jarod,

SQR seems to print based on what type of printer = you're using, i.e., HP, lineprinter, etc.  This also applies to = graphics.  So, and EPS graphic will only print correctly when = you're using a postscript printer, and a BMP graphic will only print to = a Windows printer.

When you specify to print to a file: "c:\temp = -PRINTER::WP", what you're saying is, "redirect the output = file of this SQR to my default Windows printer".  I do not = think there is another way to specify a "Windows printer" in = SQR.

HTH,

Steven Ross
Programmer/Analyst
sross@kcm.org


-----Original Message-----
From: Wallach, Jarod [mailto:JWallach@KPMG.CO.NZ]
Sent: Tuesday, July 13, 1999 12:20 AM
To: Multiple recipients of list SQR-USERS
Subject: image print


following on my last e-mail

can anyone explain how or what the -printer:wp = actually does with respect to
converting bitmaps to a printable format ?


        Jarod = Wallach
kpmg
Enabling Technologies
e-mail jwallach@kpmg.co.nz
Consultant, KPMG
135 Victoria Street
P.O. Box 996
KPMG Wellington  Phone  +64 4 3828800 = x8886
New Zealand       = Fax         +64 4 = 8021221

        = Disclaimer:

The information in this electronic mail message is = confidential and may be
legally privileged.  It is intended solely for = the addressee.  Access to
this Internet electronic mail message by anyone else = is unauthorised.  If
you are not the intended recipient, any disclosure, = copying, distribution or
any action taken or omitted to be taken in reliance = on it is prohibited and
may be unlawful. When addressed to our clients any = opinions or advice
contained in this Internet electronic mail message = are subject to the terms
and conditions expressed in the governing KPMG = client engagement letter



------_=_NextPart_001_01BECD4C.4482F316-- From owner-sqr-users@list.iex.net Tue Jul 13 12:19:46 1999 Date: Tue, 13 Jul 1999 12:57:59 -0400 From: Krisjanis Gale Subject: nasty bug with lpad() and rpad() i just discovered that if you lpad() or rpad() a string consisting of spaces with spaces, that SQRW crashes without explanation. for example: let $S=' ' let $D=lpad($S,10,' ') display $D anyone else ever run into this? does it happen with *any* case where the padding character is identical to the string being modified? (kris)janis p. gale hrsd - federal reserve bank of new york x8163 From owner-sqr-users@list.iex.net Tue Jul 13 12:59:36 1999 Date: Tue, 13 Jul 1999 10:43:06 -0700 From: David Donnelly Subject: Re: nasty bug with lpad() and rpad() Works fine for me (SQR/4.0.3/PC/Windows NT 4.0/Oracle 7.3.2.2/Jun 10 1997). What do you mean by "crashes without explanation" and what is your platform etc? Dave At 12:57 PM 7/13/1999 -0400, you wrote: >i just discovered that if you lpad() or rpad() >a string consisting of spaces with spaces, >that SQRW crashes without explanation. > >for example: > >let $S=' ' >let $D=lpad($S,10,' ') >display $D > >anyone else ever run into this? >does it happen with *any* case where >the padding character is identical to >the string being modified? > > >(kris)janis p. gale >hrsd - federal reserve bank of new york >x8163 > From owner-sqr-users@list.iex.net Tue Jul 13 13:06:08 1999 Date: Tue, 13 Jul 1999 10:50:25 PDT From: Ugandhar Mukkamala Subject: Re: nasty bug with lpad() and rpad() Works fine for me too (SQR/4.2.3/PC/Windows NT 4.0/Oracle 7.3.2.2/Apr 22 1998). Ugandhar Mukkamala >From: David Donnelly >Reply-To: SQR-USERS@list.iex.net >To: Multiple recipients of list SQR-USERS >Subject: Re: nasty bug with lpad() and rpad() >Date: Tue, 13 Jul 1999 10:43:06 -0700 > >Works fine for me (SQR/4.0.3/PC/Windows NT 4.0/Oracle 7.3.2.2/Jun 10 1997). > >What do you mean by "crashes without explanation" and what is your platform >etc? > >Dave > >At 12:57 PM 7/13/1999 -0400, you wrote: > >i just discovered that if you lpad() or rpad() > >a string consisting of spaces with spaces, > >that SQRW crashes without explanation. > > > >for example: > > > >let $S=' ' > >let $D=lpad($S,10,' ') > >display $D > > > >anyone else ever run into this? > >does it happen with *any* case where > >the padding character is identical to > >the string being modified? > > > > > >(kris)janis p. gale > >hrsd - federal reserve bank of new york > >x8163 > > > _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From owner-sqr-users@list.iex.net Tue Jul 13 13:23:02 1999 Date: Tue, 13 Jul 1999 11:04:24 -0700 From: Keri Palko Subject: for fetch only? Is there an SQR equivalent for the COBOL declare cursor for select with FOR FETCH ONLY specified? Thanks, Keri From owner-sqr-users@list.iex.net Tue Jul 13 13:27:29 1999 Date: Tue, 13 Jul 1999 13:14:31 CDT From: Stephen Ratliff Subject: No Formfeed I didn't know whether to pose it to the list or not. I am trying to print a file like a report (not using the write feature but the print command) with no page breaks and no formfeed characters. This file must be clear of all ascii/format characters. I tried using the old SQR code of no-formfeed, and it doesn't print the formfeed characters; however, it still produces a return carriage where the formfeed character would be. Using the new SQR code formfeed=no in the Declare-Layout produces the same effect. I can remove the return carriage when I increase the page size or max-lines, but unfortunately, the file's size will number more lines and inches than SQR can handle using the page-size, max-lines, or page-depth commands. Do you have any suggestions? Thanks, Stephen Ratliff _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com From owner-sqr-users@list.iex.net Tue Jul 13 16:03:01 1999 Date: Tue, 13 Jul 1999 13:19:05 -0700 From: John Sayre Subject: Re: for fetch only? From: John Sayre@GAPINC on 07/13/99 01:19 PM I use ' for fetch only ' all of the time in SQR (on DB2) queries. I put it as the last statement in the query, after all of the 'where', just before end-select. Also with DB2, you can use 'with ur' which reads through locks & won't lock tables, AKA 'dirty read' Please respond to SQR-USERS@list.iex.net To: Multiple recipients of list SQR-USERS cc: (bcc: John Sayre/SB/GAPINC) Subject: for fetch only? Is there an SQR equivalent for the COBOL declare cursor for select with FOR FETCH ONLY specified? Thanks, Keri From owner-sqr-users@list.iex.net Tue Jul 13 16:04:43 1999 Date: Tue, 13 Jul 1999 15:48:29 -0500 From: "Ross, Steven" Subject: Re: image print This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BECD71.1419579A Content-Type: text/plain; charset="iso-8859-1" Perhaps I didn't make myself clear. Since you are using a bitmap (i.e., filename.bmp) as a graphic, you need to print to a Windows printer for the graphic to print correctly. Since you're using PCL5, you should probably use the PCL5 graphics format, the name of which escapes me right now...but it's in the manual. HTH, Steven Ross Programmer/Analyst sross@kcm.org -----Original Message----- From: Jarod Wallach [mailto:Jarod.Wallach@MeridianEnergy.co.nz] Sent: Tuesday, July 13, 1999 3:37 PM To: 'sross@KCM.ORG' Cc: 'SQR-USERS@list.iex.net' Subject: RE: image print the issue for us is not necessarily to print to a windows printer. we need to be able to create the logo directly embedded into the .lis file so that the fax software (object fax) will render this correctly (the object fax is using the PCL5 converters) and therefore send the correctly formatted bitmap. at the moment if we do this the bitmap comes out as a shaded box (which usually means that the printer cant resolve the image correctly), but of course this works correctly if we use -printer:wp any suggestions would be greatly accepted many thanks Jarod Wallach mailto:jwallach@kpmg.co.nz mailto:jarod.wallach@meridianenergy.co.nz Consultant 135 Victoria Street P.O. Box 996 KPMG WellingtonPhone +64 4 3828800 ext. 8886 New Zealand Fax +64 4 8021221 Disclaimer: The information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Internet electronic mail message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Internet electronic mail message are subject to the terms and conditions expressed in the governing KPMG client engagement letter -----Original Message----- From: Ross, Steven [ mailto:sross@KCM.ORG ] Sent: Wednesday, 14 July 1999 04:25 To: Multiple recipients of list SQR-USERS Subject: Re: image print ---------- From: Ross, Steven[SMTP:SROSS@KCM.ORG] Sent: Wednesday, July 14, 1999 4:24:59 AM To: Multiple recipients of list SQR-USERS Subject: Re: image print Auto forwarded by a Rule Jarod, SQR seems to print based on what type of printer you're using, i.e., HP, lineprinter, etc. This also applies to graphics. So, and EPS graphic will only print correctly when you're using a postscript printer, and a BMP graphic will only print to a Windows printer. When you specify to print to a file: "c:\temp -PRINTER::WP", what you're saying is, "redirect the output file of this SQR to my default Windows printer". I do not think there is another way to specify a "Windows printer" in SQR. HTH, Steven Ross Programmer/Analyst sross@kcm.org -----Original Message----- From: Wallach, Jarod [ mailto:JWallach@KPMG.CO.NZ ] Sent: Tuesday, July 13, 1999 12:20 AM To: Multiple recipients of list SQR-USERS Subject: image print following on my last e-mail can anyone explain how or what the -printer:wp actually does with respect to converting bitmaps to a printable format ? Jarod Wallach kpmg Enabling Technologies e-mail jwallach@kpmg.co.nz Consultant, KPMG 135 Victoria Street P.O. Box 996 KPMG Wellington Phone +64 4 3828800 x8886 New Zealand Fax +64 4 8021221 Disclaimer: The information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Internet electronic mail message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Internet electronic mail message are subject to the terms and conditions expressed in the governing KPMG client engagement letter ------_=_NextPart_001_01BECD71.1419579A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: image print

Perhaps I didn't make myself clear.  Since you = are using a bitmap (i.e., filename.bmp) as a graphic, you need to print = to a Windows printer for the graphic to print correctly.  Since = you're using PCL5, you should probably use the PCL5 graphics format, = the name of which escapes me right now...but it's in the = manual.

HTH,

Steven Ross
Programmer/Analyst
sross@kcm.org =A0


-----Original Message-----
From: Jarod Wallach [mailto:Jarod.Wallach@= MeridianEnergy.co.nz]
Sent: Tuesday, July 13, 1999 3:37 PM
To: 'sross@KCM.ORG'
Cc: 'SQR-USERS@list.iex.net'
Subject: RE: image print


the issue for us is not necessarily to print to a = windows printer. we need
to be able to create the logo directly embedded into = the .lis file so that
the fax software (object fax) will render this = correctly (the object fax is
using the PCL5 converters) and therefore send the = correctly formatted
bitmap. at the moment if we do this the bitmap comes = out as a shaded box
(which usually means that the printer cant resolve = the image correctly), but
of course this works correctly if we use = -printer:wp
 
any suggestions would be greatly accepted
 
many thanks
 


Jarod Wallach
mailto:jwallach@kpmg.co.nz = <mailto:jwallach@kpmg.co.nz>&n= bsp;
mailto:jarod.wallach@= meridianenergy.co.nz
<mailto:jarod.wallach@= meridianenergy.co.nz> 
Consultant
135 Victoria Street
P.O. Box 996
KPMG WellingtonPhone    +64 4 3828800 = ext. 8886
New = Zealand         = Fax       +64 4 8021221

Disclaimer:
The information in this electronic mail message is = confidential and may be
legally privileged.  It is intended solely for = the addressee.  Access to
this Internet electronic mail message by anyone else = is unauthorised.  If
you are not the intended recipient, any disclosure, = copying, distribution or
any action taken or omitted to be taken in reliance = on it is prohibited and
may be unlawful. When addressed to our clients any = opinions or advice
contained in this Internet electronic mail message = are subject to the terms
and conditions expressed in the governing KPMG = client engagement letter

 

-----Original Message-----
From: Ross, Steven [ mailto:sross@KCM.ORG <mailto:sross@KCM.ORG> ]
Sent: Wednesday, 14 July 1999 04:25
To: Multiple recipients of list SQR-USERS
Subject: Re: image print







----------

From:   Ross, = Steven[SMTP:SROSS@KCM.ORG]
Sent:   Wednesday, July 14, 1999 4:24:59 = AM
To:     Multiple recipients of = list SQR-USERS
Subject:        = Re: image print
Auto forwarded by a Rule


Jarod,

SQR seems to print based on what type of printer = you're using, i.e., HP,
lineprinter, etc.  This also applies to = graphics.  So, and EPS graphic will
only print correctly when you're using a postscript = printer, and a BMP
graphic will only print to a Windows printer.

When you specify to print to a file: "c:\temp = -PRINTER::WP", what you're
saying is, "redirect the output file of this = SQR to my default Windows
printer".  I do not think there is another = way to specify a "Windows
printer" in SQR.

HTH,

Steven Ross
Programmer/Analyst
sross@kcm.org


-----Original Message-----
From: Wallach, Jarod [ mailto:JWallach@KPMG.CO.NZ
<mailto:JWallach@KPMG.CO.NZ> = ]
Sent: Tuesday, July 13, 1999 12:20 AM
To: Multiple recipients of list SQR-USERS
Subject: image print


following on my last e-mail

can anyone explain how or what the -printer:wp = actually does with respect to

converting bitmaps to a printable format ?


        Jarod = Wallach
kpmg
Enabling Technologies
e-mail jwallach@kpmg.co.nz
Consultant, KPMG
135 Victoria Street
P.O. Box 996
KPMG Wellington  Phone  +64 4 3828800 = x8886
New Zealand       = Fax         +64 4 8021221 =

        = Disclaimer:

The information in this electronic mail message is = confidential and may be
legally privileged.  It is intended solely for = the addressee.  Access to
this Internet electronic mail message by anyone else = is unauthorised.  If
you are not the intended recipient, any disclosure, = copying, distribution or

any action taken or omitted to be taken in reliance = on it is prohibited and
may be unlawful. When addressed to our clients any = opinions or advice
contained in this Internet electronic mail message = are subject to the terms
and conditions expressed in the governing KPMG = client engagement letter



------_=_NextPart_001_01BECD71.1419579A-- From owner-sqr-users@list.iex.net Tue Jul 13 16:57:48 1999 Date: Tue, 13 Jul 1999 16:23:19 -0500 From: Tom Reznicek Subject: Using Informix Directives within SQR We would like to use informix directives within SQR to force the index to be used. For example, our daily processing uses index a. However, we need to process the table differently for a once a month process that would use index b. The informix optimizer normally would pick index a. We would like to override that within SQR in the BEGIN-SQL paragraph, it would look like: BEGIN-SQL END-SQL Has anyone tried this approach or any suggestions? Thanks. From owner-sqr-users@list.iex.net Tue Jul 13 16:53:40 1999 Date: Tue, 13 Jul 1999 17:33:16 -0400 From: Krisjanis Gale Subject: Re: No Formfeed it sounds crazy, but just use a REALLY long page... like so: begin-setup page-size 9999 120 no-formfeed end-setup that's assuming of course, that your report won't be longer than 9999 lines. an alternative that i never investigated (but might work - it sounds good anyway) is to figure out which procedure(s) SQR executes upon starting a new page, then override it by defining a procedure with the same name, but empty. (kris)janis p. gale hrsd - federal reserve bank of new york x8163 >>> Stephen Ratliff Tuesday, July 13, 1999 2:14:31 PM >>> I didn't know whether to pose it to the list or not. I am trying to print a file like a report (not using the write feature but the print command) with no page breaks and no formfeed characters. This file must be clear of all ascii/format characters. From owner-sqr-users@list.iex.net Tue Jul 13 19:44:04 1999 Date: Tue, 13 Jul 1999 20:32:50 -0400 From: Steve Talley Subject: Re: Image printing Unsubscribe -----Original Message----- From: Discussion of SQR, SQRIBE Technologies's database reporting language [mailto:SQR-USERS@list.iex.net]On Behalf Of Wallach, Jarod Sent: Tuesday, July 13, 1999 12:55 AM To: Multiple recipients of list SQR-USERS Subject: Image printing I know this type of question is asked alot and I have searched the archives for an answer but... is it possible to print a logo without using one of the -printer flags. the situation is, one of our customers is using object fax to send their purchase orders out to vendors. when this runs as part of this the company logo is placed in the top left hand corner, this works fine when printed to a printer using the -printer:wp switch, ie print to file c:\temp\ -printer:wp. when the report is ran to a printer, \\servername\printer share name the logo does not print correctly. can any one help ???? Jarod Wallach kpmg Enabling Technologies e-mail jwallach@kpmg.co.nz Consultant, KPMG 135 Victoria Street P.O. Box 996 KPMG Wellington Phone +64 4 3828800 x8886 New Zealand Fax +64 4 8021221 Disclaimer: The information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Internet electronic mail message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Internet electronic mail message are subject to the terms and conditions expressed in the governing KPMG client engagement letter From owner-sqr-users@list.iex.net Wed Jul 14 08:45:21 1999 Date: Wed, 14 Jul 1999 09:34:29 -0400 From: Kimberly Lawrence Subject: Re: Using Informix Directives within SQR --0__=hlet4naIl4F4Ar5KiwYgR66INvzJn5xc5iMxl3DqUaLQFAVYAdxG3MrZ Content-type: text/plain; charset=us-ascii Content-Disposition: inline I do it like this: begin-select /*+ ORDERED*/ from table a, table b end-select You can do the same thing with an idex directive inside the /* */ syntax. Let me know if you need any help with it. Kimberly (Embedded image moved Tom Reznicek to file: 07/13/99 05:23 PM pic01909.pcx) Please respond to SQR-USERS@list.iex.net To: Multiple recipients of list SQR-USERS cc: (bcc: Kimberly Lawrence/MIS/Circuit City) Subject: Using Informix Directives within SQR We would like to use informix directives within SQR to force the index to be used. For example, our daily processing uses index a. However, we need to process the table differently for a once a month process that would use index b. The informix optimizer normally would pick index a. We would like to override that within SQR in the BEGIN-SQL paragraph, it would look like: BEGIN-SQL END-SQL Has anyone tried this approach or any suggestions? Thanks. --0__=hlet4naIl4F4Ar5KiwYgR66INvzJn5xc5iMxl3DqUaLQFAVYAdxG3MrZ Content-type: application/octet-stream; name="pic01909.pcx" Content-Disposition: attachment; filename="pic01909.pcx" Content-transfer-encoding: base64 CgUBCAAAAABoACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABaQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPH E8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sT zRPHE8MTwhPwEwzIBgzYE8wTxhPDE8IT7hPOBtcTzBPGE8MTE+wTwgbCBwbCEgbCEgbCEsUG1hPL E8YTwxMT6hMMwgYHwgLCAwISwgfEEsMCwwbVE8sTxRPDExPpE8MGAwcCBwMCwhLDB8ISwgISwgLD BtUTyhPFE8MTE+gTwgIHA8ICEw4DDgLDE8USwwLCEMIG1BPKE8UTwxMT5xMCAwcDAg4TDgITwgIS D8ISD8ISBRICEcICwwbUE8oTxRPCExPmEwYCBwMCDgIOwgLDExITEhPCEg8GxgLDBtMMDAfJE8QT whMT5hMGwwITBgMCDhLFEw8SE8ISBgIDwhIDEsMGB9MDxwwHxRPDExPlEwYHAhESAg8CwhMPwhMP xBMPxRIQwgIDAgMCBtMDxwPEDAfDE8IT4RMHwwzCBgLCEhMCDxLIE8MSD8MSwwIQAwIDBgfSDMkD wgPCDAfCExPbEwfGDMIDDAIHERITEhMSwxMPwxMPwxPDEgIDAgMCwwMCBgzREwfHDMYDDMITE9YT B8UMyAMGB8ICBhLDAsYTEhMSExIPwhIHAgcCAwUQAgYRBgfSE8UTB8QMwgMMwhMT0hMHxAzLA8IM BsISDxESExITAw4DxBMSExITwxICBwPCAsMDDMIGB9ITyRMHwwzCExPPEwfDDMkDxQwHwhMGBxIT AhECEwMOAg7DExITDxMPwxIDAgMCBwMCDAYRBgfSE8kTwhPCDMITE8wTB8MMxwPEDMIHxxMGxBLD Ag4DDgIGwg/IEgIDwgIDAgwCEMIGB9ITyRMHDAcMwhMTyhMHwgzGA8MMwgfMEwYHwhLCEAIOAg4C DhDDAhIPxhIFAgXDAgUCEQYH0hPHEwfCDAcPDMITE8gTB8IMxQPDDAfQEwbDEhDEAhAOEA4QwgLG EgcSBhIGBcMCBcIGB9ATB8UMEwfCDA8HDwwHwhMTxhMHwgzEA8MMB9MTBgfCEhADEMICDhAOEMIC EQIDxxIGBwbCAgUCEQYHyxMHxAwHwhMHEwzCEwcPBw8MB8MTE8UTBwzEA8IMB9YTBsQSEAMCA8UC EQIDAgPDEgcSBgfCBgUQAhDCBgfGEwfEDAfGE8INEwzCEw8HwgwHwxPCE8QTBwzDA8IMB9gTBgfE EhACEMYCEQIDAsQSBhLDBsICEALCBgfCEwfDDAfKEwfCDRMHwhPCDAfEE8ITE8MTBwzCA8IMB9oT DBIHwxLDDBEDxQIDAgPDEgYSBgfCBgIQAhAGDAfCEwzDE8MHyRMHwhPCBxMHxRPDExPDEwzCAwwH 3RMGxxICEQPDAgMCA8MSBhIGBwYMBhACEAIGDMMTDBPCB8YTwwfHEwfGE8MTwhPDEwwDDAfeEwYH xxICEQPDAgMCwhIGEgYHBgwGEAIQAsIGB8MTDMYTwwfKEwzGE8MTwhPDE8IMB98TDBLCB8USAgMR xAISB8ISBgcGDAYQBhAGEAYMB8MMB8kTwwfHEwzGE8MTwhPDEwwPwgzfEwYSB8ISB8ISAhECAwID EgcSBwYHBgwGEAYQxgzDD8IHxRPDB8kTBwzGE8MTwhPDEwzDD8QM3BPCBhIGwxIGAhECAwIHBgcG yAzJDxMHzRMHwwwHxxPDE8ITwxMHDMYPxwwH1BMGEgYSBhLLDM4PwwwTDMcTwgfEDAfJE8QTwhMT xBMHwgzLD9sM0w/GDAfDEwzDEwfEDAfLE8YTwxMTxhMHxAztD8gMBgfIE8QMB84TxxPDE8ITyhMH xwzbD8sMEAUMBcIMwgYH1RPKE8UTwxMT0RMH2wwGEAYQBhACBQwFDAUMBgwHBgfWE8sTxRPDExPu EwYMBhAGEAIGDAYMwwYH1xPLE8YTwxMT8BPKBgfYE8wTxhPDExP1E9sTzRPHE8MTwhP1E9sTzRPH E8MTwhMMAAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD/ /wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8A AAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A //8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAA AP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA /wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCk gICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vw oKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw //vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzA psrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDA wNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICA wMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACA AICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACA gACA//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP////// --0__=hlet4naIl4F4Ar5KiwYgR66INvzJn5xc5iMxl3DqUaLQFAVYAdxG3MrZ-- From owner-sqr-users@list.iex.net Wed Jul 14 11:19:44 1999 Date: Wed, 14 Jul 1999 10:52:36 -0500 From: Debra Benton Subject: Postscript printing and printing images This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BECE11.02C32764 Content-Type: text/plain; charset="iso-8859-1" Hello All, You will probably hear from me quite a bit today - I apologize for the inconvenience. I am having problems printing images and getting the postscript *.lis file to print the right place on a file. Image printing. I know there have been multiple e-mails regarding image printing, but I am still having problems. I need to print to a file and then send the *.lis file to a printer because this company will outsource the printing of their invoices to a third party printer. I know that I can use a bitmap and send it directly to my laserjet printer here using -PRINTER:WP. I also know that because I am using DOS to send my file to the printer, that I cannot use a bitmap file. I've had the bitmap converted to a *.gif file and an *.eps file. Using both the LASERJET and POSTSCRIPT printer configurations, I still receive either a grey box or a box with a line through it. I know there are also HPGL-FILE and JPEG-FILE types to test. Am I just using the wrong type of file? If yes, can anyone recommend some SHAREWARE that can convert a *.bmp/*.gif/*.eps file to one of these formats. I've tried downloading Adobe and several other shareware files, but their demo copies do not let you save. Postscript printing. When I change my printer definition from LASERJET to POSTSCRIPT (this made my French characters work thanks to a a POSTSCRI.STR file from Franck Masson - they still don't work on the LASERJET definition, although I think I need to use a symbol-set other than the default OU), I get a printed page that cuts off the top of my invoice and essentially moves the entire page up about half way. I assumed that I might have some problems with my page size/orientation. Here are the paramenters I have: type = POSTSCRIPT left-margin=.25 top-margin=.25 font=3 ! Font number font-style=fixed lines-inch=7 ! Lines per inch point-size=6 orientation=portrait ! portrait or landscape #define PAGE_MAX_COLS 135 #define PAGE_MAX_LINES 79 page-size = 79 135 I tried commenting out the top-margin and the page-size to use the defaults with no luck. Any help would be appreciated. I am attaching the eps file, the gif file, the bitmap file and the postscri.str file. Thanks, Debbie <> <> <> <> ------_=_NextPart_000_01BECE11.02C32764 Content-Type: image/bmp; name="logo.bmp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="logo.bmp" Content-Location: ATT-0-4750B49FE439D3118A2B00A0C9E1483D-l ogo.bmp Qk0uPwAAAAAAADYEAAAoAAAAJgEAADMAAAABAAgAAAAAAPg6AADEDgAAxA4AAAAAAAAAAAAA//// APr18wD8+fcA+fTxAPLy8gD17OcA9OnjAObm5gDz5uAA8uXfAO7d1QDs2dAA2dnZAMzMzADmzcEA 4cO0AL+/vwDfvq4As7OzANu3pQDWsZ4A166aAKWlpQDSpY4Az6OMAJmZmQDOnYQAy5Z8AMeTeACM jIwAxY5yAMSJawCAgIAAwYVnALp7WgB0dHQAtXRRALNrRgBmZmYArWM8AFpaWgCqWTAAp1kwAKRT KABMTEwAo00gAJ9NIQCfSRsAQEBAAJ5FFwCcQREAlEESAJw6CQCUOgkAjjoJAIM5BwAzMzMAmTMA AI0zAACEMwAAezMAAHUzAABmMwAAZgAAAMDAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAESUGAAAA AAAAAAAAAAAAAAAAAAAAAAABOQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAKLzIiBQAAAAAAAAAAAAAAAAAAAAAAAAAxGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAACFS00IgAAAAAAAAAAAAAAAAAAAAAAACcvAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxcyOR4FAAAAAAAAAAAAAAAAAAAAGDkAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEbNDIaBQAAAAAAAAAA AAAAAAAOOQ4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB IjkxGgUAAAAAAAAAAAAAAAI0GgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABiIyMh4CAAAAAAAAAAAAACoqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4lMjQbAQAAAAAAAAAAITkDAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPKjQxGAMAAAAAAAAROREAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEy01LhgF AAAAAAk0HgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAARQrNS4YAQAAADErAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhkZGRkZAAAA AAAAABYdGRIAAAAAAAAAAAQWHRkSAAAAAAAAAAcZGRIAEhkZDQAAAAAAEBkZDAwZGQ0AAAAAAAAS GRkZGRkAAAAAAAAHGRkZGRkNAAAAAAAAEhkZGRYMAAAAAAAAAAAAAAAAABIZEgcZGRAHGRkHAAAA AAQZGRIAAA0ZGQ0AAAAAAAcZGRIAGRkZAAAAAAAAAAAZGRkAAAAAAAAAABAZGQcAAAAAAAAQGRIA EhkZGQAAAAAAAAAAAAAAAAAAAAYaLjk0FwAAJTUKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAZODg4ODgHAAAAAAAmODg4OCwMAAAAAAAAKDg4ODgoBAAAAAAABDg4KAAsODgNAAAAAAAWODgZ DTg4JgAAAAAAACA4ODg4OAcAAAAAAAc4ODg4OCMAAAAAAAAdODg4ODgjBAAAAAAAAAAAAAAAGTg4 DTg4LAw4OBAAAAAAACA4OBANJjg4EAAAAAAAADg4LAAwODgAAAAAAAAAACg4OAcAAAAAAAAAGTg4 GQAAAAAAABk4MAAmODg4BAAAAAAAAAAAAAAAAAAAAAAJHzI1MRcaOhUAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABA4OCwZGQcAAAAADDg4LA04OCgAAAAAAA04OCwSODggAAAAAAAAKDg4DTg4 LAAAAAAAAA04OCYAODgwAAAAAAAAFjg4JhkZBwAAAAAAACw4OBkZEgAAAAAAABI4OCAdODgjAAAA AAAAAAAAAAAQODgWODg4Ejg4GQAAAAAABzg4ODg4ODgNAAAAAAAAKDg4BCY4OAAAAAAAAAAAIDg4 EAAAAAAAAAANODgjAAAAAAAADTg4BzA4ODgNAAAAAAAAACQRAAAAAAAAAAAACSIyNis1IgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzg4KAAAAAAAAAANODgmACM4OBIAAAAADTg4JgANDQ0A AAAAAAAgODgmODgdAAAAAAAAADg4MCY4ODgMAAAAAAAMODgsJiYMAAAAAAAAIzg4JiYdAAAAAAAA DDg4JgAoODgMAAAAAAAAAAAAAAc4OBY4MDgmJjgmAAAAAAAAIDg4HSw4OAcAAAAAAAAdODgoODg4 AAAAAAAAAAAWODgZAAAAAAAAAAQ4ODAAAAAAAAAAODgSODgsOBkAAAAAAAAAITkPAAAAAAAAAAAA AAskMzwvFwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALDg4BAAAAAAAAAQ4ODgAGTg4HQAA AAAHODg4AAAAAAAAAAAAABY4ODg4OBAAAAAAAAAAKDg4ODg4OBIAAAAAAAA4ODg4OBkAAAAAAAAZ ODg4ODgAAAAAAAAAMDgwAB04OBkAAAAAAAAAAAAAADA4HTgmKDgjODAAAAAAAAAHMDgWJjg4AAAA AAAAABI4ODg4OCAEAAAAAAAAAAw4OCYAAAAAAAAAACg4OAcAAAAAAAAoOCg4OCM4JgAAAAAAAAAC JDkTAAAAAAAAAAAAAAAPKzs6LhgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjODgNAAAAAAAA ACY4OBANODgmAAAAAAAmODgNDCYmEgAAAAAADDg4JjA4LAQAAAAAAAAdODgmIDg4HQAAAAAAACY4 OBANBwAAAAAAAA04OCMNDQAAAAAAAAAmODgHGTg4GQAAAAAAAAAAAAAAIzgoOCwSOCw4OAwAAAAA AAAZOCwSODAAAAAAAAAADDg4Jgc4OCAAAAAAAAAAADg4OAAAAAAAAAAAIDg4EAAAAAAAACA4ODgm GTgwAAAAAAAAAAAAJDQPAAAAAAAAAAAAAAAfOiszNjQYAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABk4OBkAAAAAAAAADDA4MCw4OBYAAAAAAAwwODAsODgWAAAAAAAAODgwDTg4IwAAAAAAABI4OB0M ODgmAAAAAAAAHTg4ODg4BwAAAAAAADg4ODg4IAAAAAAAABk4OCgwODgSAAAAAAAAAAAAAAAZODg4 OAQwODg4EgAAAAAAAAQwOCA4JgAAAAAAAAAAMDgwJjg4OAAAAAAAACA4ODg4ODgAAAAAAAAWODgZ AAAAAAAAEjg4OCYNODgHAAAAAAAAAAADJTkUAAAAAAAAAAAAABU1KhMxNjcvGgUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADTg4IwAAAAAAAAAADCY4ODgmBAAAAAAAAAwoODg4JgQAAAAAAAAmODgHHTg4 GQAAAAAADDg4JgAwODgAAAAAAAAQODg4ODgQAAAAAAAAKDg4ODgoAAAAAAAAEDg4ODgsGQAAAAAA AAAAAAAAAA04ODg4ACA4ODgdAAAAAAAAABk4ODgmAAAAAAAAAAAmODg4ODgdAAAAAAAAEjg4ODg4 OA0AAAAAAAw4OCYAAAAAAAAMODg4GQA4OBIAAAAAAAAAAAAFKjIUAAAAAAAAAAAACTQyAQAXMjc3 KxsFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcNBwAAAAAAAAAAAAAHDQQAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADJzkYAAAAAAAA AAAANDYPAAAFHi43Ny4eAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAJKjUUAAAAAAAAAAAlOyIAAAAACiIuPDc5GwUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAFNDUYAAAAAAAAABo3MgAAAQMDAw4nMz03MR8KAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMDAwgICAgLCwsODg4ODw8P ExMVFBcXFxcbGxseHh4eIiUlJScnJykpKSkvNDUqLi8vLy8xMjY5MS8uLi4uLjM1Oj4+PC4hCgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKSstLS0tMTExMjI0NDQ0NDQ5OTk0NDQ0NDk5 OTU1NTU1NTU1NTU1Ojo6Ojo6Ojo6Ojo6Ojo7Ozs7Ozs7Ozs7Ozs7PDw6Ozs7Ozs7PD08PDw8PDw8 PDw8PDw8PDo0JQkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcIR8fHx8eHh4bGxsbGhoa GhcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXMjUlGhoa GhopPCcXFxUXFxcXFxcXFxcXFxghCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAATMTUhAAAAACE8LwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAATLzUbAAAAEzMzCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXNTMiAQAKMTsXAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcMzciAAArPSkAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfMzck AyQ9MgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEhNjYkHDczDwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAIlNzcnMzwfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMkNzc0PS8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYqNz4+NAoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAt PD42FAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAoqPTwkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAk0PS4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4qMw4AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA40GgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABEiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------_=_NextPart_000_01BECE11.02C32764 Content-Type: application/octet-stream; name="logo.eps" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="logo.eps" Content-Location: ATT-1-4850B49FE439D3118A2B00A0C9E1483D-l ogo.eps xdDTxrInAADi/QEAAAAAAAAAAAAeAAAAlCcAAP//SUkqAAgAAAAOAP4ABAABAAAAAAAAAAABAwAB AAAA3QAAAAEBAwABAAAAJgAAAAIBAwABAAAACAAAAAMBAwABAAAAAQAAAAYBAwABAAAAAwAAABEB BAABAAAAxgYAABUBAwABAAAAAQAAABYBAwABAAAAJgAAABcBBAABAAAAziAAABoBBQABAAAAtgAA ABsBBQABAAAAvgAAACgBAwABAAAAAgAAAEABAwAAAwAAxgAAAAAAAADaAgsAECcAANoCCwAQJwAA ///z8/f38fHy8ufn4+Pm5uDg39/V1dDQ2dnMzMHBtLS/v66us7OlpZ6empqlpY6OjIyZmYSEfHx4 eIyMcnJra4CAZ2daWnR0UVFGRmZmPDxaWjAwMDAoKExMICAhIRsbQEAXFxEREhIJCQkJCQkHBzMz AAAAAAAAAAAAAAAAAADAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ //X1+fn09PLy7Ozp6ebm5ubl5d3d2dnZ2czMzc3Dw7+/vr6zs7e3sbGurqWlpaWjo5mZnZ2WlpOT jIyOjomJgICFhXt7dHR0dGtrZmZjY1paWVlZWVNTTExNTU1NSUlAQEVFQUFBQTo6Ojo6Ojk5MzMz MzMzMzMzMzMzMzMAAMDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP// +vr8/Pn58vL19fT05ubz8/Ly7u7s7NnZzMzm5uHhv7/f37Oz29vW1tfXpaXS0s/PmZnOzsvLx8eM jMXFxMSAgMHBurp0dLW1s7NmZq2tWlqqqqenpKRMTKOjn5+fn0BAnp6cnJSUnJyUlI6Og4MzM5mZ jY2EhHt7dXVmZmZmwMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA40AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0PS4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACj08JAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAtPjYUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAkNzc9LwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjc3Jzwf AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhNiQcMw8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcMzcAACspAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADUzIgAKMRcAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAATNRsAABMzCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACEfHx8eHh4bGxsaGhoXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcX FxcXFxcXFxcXFxcXMjUaGhoaKTwXFxUXFxcXFxcXFxgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKy0tLTExMTI0NDQ0NDk5NDQ0NDk5NTU1NTU1NTU6Ojo6Ojo6Ojo6Ojs7Ozs7 Ozs7Ozw8Ojs7Ozs8PTw8PDw8PDw8PDw6NAkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAADAwMICAgLCw4ODg8PExMVFxcXGxsbHh4eJSUlJycpKSkvNSou Ly8vMjY5Ly4uLi4zOj4+LiEKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJKjUAAAAAAAAlOyIA AAAiLjw5GwUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAADQcAAAAAAAAABw0EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACc5GAAAAAAAADQ2DwAFHjc3LgMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADTgj AAAAAAAADCY4OCYAAAAAAAw4ODgEAAAAAAA4OAc4OBkAAAAMODgAMDgAAAAAABA4ODgQAAAAAAA4 ODgoAAAAAAA4ODgsGQAAAAAAAAAAAA04ODggODgdAAAAAAAZODgmAAAAAAAAJjg4ODgdAAAAABI4 ODg4DQAAAAAMOCYAAAAADDg4GQA4EgAAAAAAAAAFMhQAAAAAAAAANDIBFzI3KxsFAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjOA0AAAAAACY4 OA04OAAAAAAmOA0MJhIAAAAADDgmMCwEAAAAAB04OCA4OAAAAAAAJjgQDQAAAAAADTgjDQAAAAAA ADg4Bzg4GQAAAAAAAAAAIyg4LDgsOAwAAAAAADgsEjAAAAAAAAA4OCY4OCAAAAAAAAA4OAAAAAAA ACA4EAAAAAAgODgmGTgAAAAAAAAAJDQAAAAAAAAAAAA6KzM0GAEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACw4BAAAAAAAODg4GTg4AAAA Bzg4AAAAAAAAAAAWODg4EAAAAAAAKDg4ODg4AAAAAAA4ODg4AAAAAAAZODg4AAAAAAAAODAAODgZ AAAAAAAAAAAwHTgmOCM4AAAAAAAHOBYmOAAAAAAAADg4ODggBAAAAAAADDgmAAAAAAAAKDgHAAAA ACg4KDgjOAAAAAAAACQ5EwAAAAAAAAAADzs6LgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHODgAAAAAAAA4OCYjODgAAAANODgADQ0A AAAAACA4JjgdAAAAAAA4ODA4ODgAAAAADDgsJiYAAAAAACM4JiYAAAAAAAw4JgA4OAwAAAAAAAAA BzgWODAmJjgAAAAAACA4HSw4BwAAAAAAODgoODgAAAAAAAAWOBkAAAAAAAQ4MAAAAAAAODgSOCw4 AAAAAAAAOQ8AAAAAAAAACyQzLxcDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABk4ODg4BwAAACY4ODgsDAAAAAAoODg4KAAAAAAEOCgA LDgNAAAAADg4GTg4JgAAAAAgODg4OAAAAAAHODg4OAAAAAAAHTg4OCMEAAAAAAAAAAAZOA04OAw4 OAAAAAAgOBANJjgQAAAAAAA4LAA4OAAAAAAAACg4BwAAAAAAGTgZAAAAAAA4MAA4ODgAAAAAAAAA AAAAAAAJHzIxFxoVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEhkZGRkAAAAAABYdEgAAAAAAAAQWGRIAAAAAAAcZEgASGQ0AAAAA GRkMGRkNAAAAABIZGRkZAAAAAAcZGRkZAAAAAAASGRkWAAAAAAAAAAAAABIZBxkZBxkZAAAABBkZ AAANGQ0AAAAABxkSABkZAAAAAAAAGRkAAAAAAAAQGQcAAAAAABkSABkZGQAAAAAAAAAAAAAABi45 NAAAJQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARQrLhgBAAAxAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADyoxGAMAAAAAETkAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUyNAEAAAAAAAAhOQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAYiMh4CAAAAAAAAACoqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAARsyGgUAAAAAAAAAAAAOOQ4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABcyOQUAAAAAAAAAAAAAABg5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIVNCIAAAAA AAAAAAAAAAAAJy8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARJQYAAAAAAAAAAAAAAAAA AAA5CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACUhUFMtQWRvYmUtMy4wIEVQU0YtMy4wDQolJUNyZWF0b3I6IEFkb2Jl IFBob3Rvc2hvcCBWZXJzaW9uIDQuMA0KJSVUaXRsZTogbG0wNzE0OTktbG9nby5lcHMNCiUlQ3Jl YXRpb25EYXRlOiBXZWQgSnVsIDE0IDE5OTkgMTA6MTA6NTUNCiUlQm91bmRpbmdCb3g6IDAgMCAy MjEgMzgNCiUlSGlSZXNCb3VuZGluZ0JveDogMCAwIDIyMC41IDM4LjI1DQolJVN1cHByZXNzRG90 R2FpbkNvbXBlbnNhdGlvbg0KJSVFbmRDb21tZW50cw0KJSVCZWdpblByb2xvZw0KJSVFbmRQcm9s b2cNCiUlQmVnaW5TZXR1cA0KJSVFbmRTZXR1cA0KJUltYWdlRGF0YTogMjk0IDUxIDggMyAxIDI5 NCAyICJiZWdpbmltYWdlIg0KJUJlZ2luUGhvdG9zaG9wOiAxNzE0DQolMzg0MjQ5NEQwM0VEMDAw MDAwMDAwMDEwMDA2MDAwMDAwMDAxMDAwMTAwNjAwMDAwMDAwMTAwMDEzODQyNDk0RA0KJTAzRjMw MDAwMDAwMDAwMDgwMDAwMDAwMDAwMDAwMDAwMzg0MjQ5NEQwNDBBMDAwMDAwMDAwMDAxMDAwMDM4 NDINCiU0OTREMjcxMDAwMDAwMDAwMDAwQTAwMDEwMDAwMDAwMDAwMDAwMDAyMzg0MjQ5NEQwM0Y1 MDAwMDAwMDAwMDQ4DQolMDAyRjY2NjYwMDAxMDA2QzY2NjYwMDA2MDAwMDAwMDAwMDAxMDAyRjY2 NjYwMDAxMDBBMTk5OUEwMDA2MDAwMA0KJTAwMDAwMDAxMDAzMjAwMDAwMDAxMDA1QTAwMDAwMDA2 MDAwMDAwMDAwMDAxMDAzNTAwMDAwMDAxMDAyRDAwMDANCiUwMDA2MDAwMDAwMDAwMDAxMzg0MjQ5 NEQwM0Y4MDAwMDAwMDAwMDcwMDAwMEZGRkZGRkZGRkZGRkZGRkZGRkZGDQolRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGMDNFODAwMDAwMDAwRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRg0KJUZG RkZGRkZGRkZGRkZGRkYwM0U4MDAwMDAwMDBGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCiVGRkZGRkZGRjAzRTgwMDAwMDAwMEZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGDQolMDNFODAwMDAzODQyNDk0RDA0MDgwMDAwMDAwMDAwMTAwMDAwMDAw MTAwMDAwMjQwMDAwMDAyNDAwMDAwMDAwMA0KJTM4NDI0OTREMDQwOTAwMDAwMDAwMDU1NDAwMDAw MDAxMDAwMDAwODAwMDAwMDAxNjAwMDAwMTgwMDAwMDIxMDANCiUwMDAwMDUzODAwMTgwMDAxRkZE OEZGRTAwMDEwNEE0NjQ5NDYwMDAxMDIwMTAwNDgwMDQ4MDAwMEZGRkUwMDI3DQolNDY2OTZDNjUy MDc3NzI2OTc0NzQ2NTZFMjA2Mjc5MjA0MTY0NkY2MjY1MjA1MDY4NkY3NDZGNzM2ODZGNzBBOA0K JTIwMzQyRTMwMDBGRkVFMDAwRTQxNjQ2RjYyNjUwMDY0ODAwMDAwMDAwMUZGREIwMDg0MDAwQzA4 MDgwODA5MDgNCiUwQzA5MDkwQzExMEIwQTBCMTExNTBGMEMwQzBGMTUxODEzMTMxNTEzMTMxODEx MEMwQzBDMEMwQzBDMTEwQzBDDQolMEMwQzBDMEMwQzBDMEMwQzBDMEMwQzBDMEMwQzBDMEMwQzBD MEMwQzBDMEMwQzBDMEMwQzAxMEQwQjBCMEQwRQ0KJTBEMTAwRTBFMTAxNDBFMEUwRTE0MTQwRTBF MEUwRTE0MTEwQzBDMEMwQzBDMTExMTBDMEMwQzBDMEMwQzExMEMNCiUwQzBDMEMwQzBDMEMwQzBD MEMwQzBDMEMwQzBDMEMwQzBDMEMwQzBDMEMwQzBDMEMwQzBDMENGRkMwMDAxMTA4DQolMDAxNjAw ODAwMzAxMjIwMDAyMTEwMTAzMTEwMUZGREQwMDA0MDAwOEZGQzQwMTNGMDAwMDAxMDUwMTAxMDEw MQ0KJTAxMDEwMDAwMDAwMDAwMDAwMDAzMDAwMTAyMDQwNTA2MDcwODA5MEEwQjAxMDAwMTA1MDEw MTAxMDEwMTAxMDANCiUwMDAwMDAwMDAwMDAwMTAwMDIwMzA0MDUwNjA3MDgwOTBBMEIxMDAwMDEw NDAxMDMwMjA0MDIwNTA3MDYwODA1DQolMDMwQzMzMDEwMDAyMTEwMzA0MjExMjMxMDU0MTUxNjEx MzIyNzE4MTMyMDYxNDkxQTFCMTQyMjMyNDE1NTJDMQ0KJTYyMzMzNDcyODJEMTQzMDcyNTkyNTNG MEUxRjE2MzczMzUxNkEyQjI4MzI2NDQ5MzU0NjQ0NUMyQTM3NDM2MTcNCiVEMjU1RTI2NUYyQjM4 NEMzRDM3NUUzRjM0NjI3OTRBNDg1QjQ5NUM0RDRFNEY0QTVCNUM1RDVFNUY1NTY2Njc2DQolODY5 NkE2QjZDNkQ2RTZGNjM3NDc1NzY3Nzc4Nzk3QTdCN0M3RDdFN0Y3MTEwMDAyMDIwMTAyMDQwNDAz MDQwNQ0KJTA2MDcwNzA2MDUzNTAxMDAwMjExMDMyMTMxMTIwNDQxNTE2MTcxMjIxMzA1MzI4MTkx MTRBMUIxNDIyM0MxNTINCiVEMUYwMzMyNDYyRTE3MjgyOTI0MzUzMTU2MzczMzRGMTI1MDYxNkEy QjI4MzA3MjYzNUMyRDI0NDkzNTRBMzE3DQolNjQ0NTU1MzY3NDY1RTJGMkIzODRDM0QzNzVFM0Yz NDY5NEE0ODVCNDk1QzRENEU0RjRBNUI1QzVENUU1RjU1Ng0KJTY2NzY4Njk2QTZCNkM2RDZFNkY2 MjczNzQ3NTc2Nzc3ODc5N0E3QjdDN0ZGREEwMDBDMDMwMTAwMDIxMTAzMTENCiUwMDNGMDBGNTU0 OTAzMzg2NTNCMEIyMDYxOTBEQ0EzNTNDNjNCOEM0MEIzNjlGNDg5RERCOUJGQ0UyQTk5NkNFDQol QjRFQjcwNUI4NkY2QjY5Njk2QkIzNUY2NkRERUUwMEQ3Qjk5QjVBQ0IxOUVGQUJFRDFGQ0NFQ0ZE M0ZBM0ZBNA0KJUY0QkU5QTUzQTQ5MkNGQzYxRDYxQjZFNzU5OTI1QUY2RUUzRjYyQTVCQjQzNzYw MUZBMkZEMjQ3QUJFQUQ5RkYNCiUwMDZBM0Q1RjY3RkExRkY4NEE1NjUzRjVBOUJEMUJEM0FFRTY1 OUQ1NUQ2MzgzQUU3NkMwQzZCMDA3N0E2RUE5DQolQTJBREFFRjUzNjU1QkZENUFGRjlDQkFFRkYw MDA3RTlBNEE3NzUyNTlDQ0E3QUMwRUE1OEMxRjdFRUMwQTcxQQ0KJTJGNzQzMDNBREM4OUQ5MzYz NzY3QjE5QjdGNEJGQTBGNEJGNDlGRTYyMDYzMzNFQjAxQzFDOTc2NEJDOENCQjYNCiVFRkQxMzFB NkEyMkJBMEJDN0YzMDdEMjZCN0Q1NjYzQkRGRkQyQkQ2RkQyRDQ5MjlEODQ5NjdEOTVGNTkxRDFE DQolQjUzNkRBQ0Y1NDJDNjMxRjdCNDBEODFDNEI1Qjc1Q0M2QkRCQjdEOENERjYzN0Y0N0VGRjAw REM1NDcxQTlGQQ0KJUQ4Q0U4RUZBRUZCQUJCN0E5RDk2RkIyRDNCMUEyQkFBMTlCQkY5QkE1RDUz RUNGNjVCRTk3RTg1RkYwMENGMzMNCiVENDQ5NEVGMjRCOUZFQUREMjMyQjIzQThFMjU5ODk4NzhD MzE4QkMzRjM5Q0Y2NTI1Q0VERDY1NkVCNzc3QUI0DQolRENGN0VEQTFCNzdGMzc2NTNGQTRCQkY5 Q0ZEMUE1RkYwMDM3QjZFNTc1MUM4RkIzNjI1OTQ5NjAxRDM3MTBEMQ0KJTQ4Njg3MEFEQTVFRkJB REY0N0Q2RjdFNDdCN0Y5Q0ZGMDBEMTdCMUI3MkVDM0VERkZEMDU3NTQ3QjlGQjNGRjQNCiUyN0Ew NTBCQUVBQThBOUY3NUNFMTVENzU4MkU3QkREQTAwMDc3NUNFNjRGRDVDQzgzNUY0RDE0NjM2MUZB OENGDQolNERCRDREREY2N0EzREYyNkJGNUVEQTc3RDNGOUJFOURDREQ5RTlEN0ZEMjNGRTBENUFC RkE0NzQ0NkU3MzVCRg0KJTYwQTJENzMwMEY0RjFBOEExOUY5RDJENzVGOTZGMkQ2NTRDNjZEREZF ODU1NzNGNjdFOEVDN0Q3RjY4QzhGNEINCiVFQ0UwQ0E0M0EwRkI3RkY0MTRDNjMxMjc3M0Y2N0ZF ODREOEU5RDk5OUI5QkQ0RjMwQkRBNkFDM0M2MENBRTk2DQolMTZFRDczOUNGNkI2RTdCRUZEREVF NkJEOTVGQTRGQUFCRjY3RThCMjdGNEZGQTZGRTZGNTE3M0I4OUY1NkJBNw0KJTY2Q0U0RTVFMjYz RDc1MUIxQ0VBQjFBOEFEQUQwNDM1Q0VBRUJCMUY5MEREQjY1RDVEOTVCMTk2RDc1RDdGNjcNCiVB N0ZEMkQ1NkFERUEzMUU4QzdBODUzOEY1QjI5QTlCRjQ2QkFEQTFBRDEzQUU4RDZDMzUyQzdDNTVF QTFFMzc3DQolRkIxMzkzODZGRDI3NkQyQUI0RkI1MjI0OTI0OUVDNkZGRkQwRjU1NDk3Q0FBOTI0 QTdFQUE0OTdDQUE5MjRBNw0KJUVBQTQ5N0NBQTkyNEE3RUFBNDk3Q0FBOTI0QTdFQUE0OTdDQUE5 MjRBN0VBNENBMEMzNDNGRDQzNjA2MDFFRUYNCiU0QjdFRjIzRjkxRTg3RTlGRkVEOUZEMjI3QzZG QjM3RDlEOUY2NEQ5RjY3OEZEMTdBNTFCMjNGRTBGNjdCMTdDDQolQjQ5MjFGQTVEMzZGRjA5NzdF OEY1REZGMDBDMTdFQTNDMUZCMzdEOEIxRkVDOUFFMzdBNENGNDM5RkU2RjY4Rg0KJTRCRTk3QkJF ODdFRjIzQUY5NTUyNDg2QzM2REJBNkM4OTZFNzdERkFFRUZENTQ5MkY5NTUyNDUwRkYwMEZGRDkN CiUzODQyNDk0RDAzRkQwMDAwMDAwMDAwMDYwMTAxMDAwMDAwMDANCiVFbmRQaG90b3Nob3ANCmdz YXZlDQovaGFzY29sb3INCi9kZXZpY2VpbmZvIHdoZXJlDQp7cG9wIGRldmljZWluZm8gL0NvbG9y cyBrbm93bg0Ke2RldmljZWluZm8gL0NvbG9ycyBnZXQgZXhlYyAxIGd0fQ0Ke2ZhbHNlfSBpZmVs c2V9DQp7L3N0YXR1c2RpY3Qgd2hlcmUNCntwb3Agc3RhdHVzZGljdCAvcHJvY2Vzc2NvbG9ycyBr bm93bg0Ke3N0YXR1c2RpY3QgL3Byb2Nlc3Njb2xvcnMgZ2V0IGV4ZWMgMSBndH0NCntmYWxzZX0g aWZlbHNlfQ0Ke2ZhbHNlfSBpZmVsc2V9DQppZmVsc2UNCmRlZg0KNDAgZGljdCBiZWdpbg0KL19p bWFnZSBzeXN0ZW1kaWN0IC9pbWFnZSBnZXQgZGVmDQovX3NldGdyYXkgc3lzdGVtZGljdCAvc2V0 Z3JheSBnZXQgZGVmDQovX2N1cnJlbnRncmF5IHN5c3RlbWRpY3QgL2N1cnJlbnRncmF5IGdldCBk ZWYNCi9fc2V0dHJhbnNmZXIgc3lzdGVtZGljdCAvc2V0dHJhbnNmZXIgZ2V0IGRlZg0KL19jdXJy ZW50dHJhbnNmZXIgc3lzdGVtZGljdCAvY3VycmVudHRyYW5zZmVyIGdldCBkZWYNCi9ibGFuayAw IF9jdXJyZW50dHJhbnNmZXIgZXhlYw0KMSBfY3VycmVudHRyYW5zZmVyIGV4ZWMgZXEgZGVmDQov bmVnYXRpdmUgYmxhbmsNCnswIF9jdXJyZW50dHJhbnNmZXIgZXhlYyAwLjUgbHR9DQp7MCBfY3Vy cmVudHRyYW5zZmVyIGV4ZWMgMSBfY3VycmVudHRyYW5zZmVyIGV4ZWMgZ3R9DQppZmVsc2UgZGVm DQovaW52ZXJ0ZWQ/IG5lZ2F0aXZlIGRlZg0KL2xldmVsMiBzeXN0ZW1kaWN0IC9sYW5ndWFnZWxl dmVsIGtub3duDQp7bGFuZ3VhZ2VsZXZlbCAyIGdlfSB7ZmFsc2V9IGlmZWxzZSBkZWYNCi9mb3Vy ZXEgezQgaW5kZXggZXEgOCAxIHJvbGwNCjQgaW5kZXggZXEgOCAxIHJvbGwNCjQgaW5kZXggZXEg OCAxIHJvbGwNCjQgaW5kZXggZXEgOCAxIHJvbGwNCnBvcCBwb3AgcG9wIHBvcCBhbmQgYW5kIGFu ZH0gZGVmDQpoYXNjb2xvciB7L2JhbmQgMCBkZWZ9IHsvYmFuZCA1IGRlZn0gaWZlbHNlDQovc2V0 Y215a2NvbG9yIHdoZXJlIHtwb3ANCjEgMCAwIDAgc2V0Y215a2NvbG9yIF9jdXJyZW50Z3JheSAx IGV4Y2ggc3ViDQowIDEgMCAwIHNldGNteWtjb2xvciBfY3VycmVudGdyYXkgMSBleGNoIHN1Yg0K MCAwIDEgMCBzZXRjbXlrY29sb3IgX2N1cnJlbnRncmF5IDEgZXhjaCBzdWINCjAgMCAwIDEgc2V0 Y215a2NvbG9yIF9jdXJyZW50Z3JheSAxIGV4Y2ggc3ViDQo0IHs0IGNvcHl9IHJlcGVhdA0KMSAw IDAgMCBmb3VyZXEgey9iYW5kIDEgc3RvcmV9IGlmDQowIDEgMCAwIGZvdXJlcSB7L2JhbmQgMiBz dG9yZX0gaWYNCjAgMCAxIDAgZm91cmVxIHsvYmFuZCAzIHN0b3JlfSBpZg0KMCAwIDAgMSBmb3Vy ZXEgey9iYW5kIDQgc3RvcmV9IGlmDQowIDAgMCAwIGZvdXJlcSB7L2JhbmQgNiBzdG9yZX0gaWZ9 IGlmDQpibGFuayB7L2JhbmQgNiBzdG9yZX0gaWYNCmdzYXZlDQovcm93cyA1MSBkZWYNCi9jb2xz IDI5NCBkZWYNCjIyMC41IDM4LjI1IHNjYWxlDQpsZXZlbDIgew0KYmFuZCAwIGVxIHsNCi9EZXZp Y2VSR0INCn0gey9EZXZpY2VHcmF5fSBpZmVsc2UNCnNldGNvbG9yc3BhY2V9IGlmDQovcGljc3Ry MSAyOTQgc3RyaW5nIGRlZg0KL3BpY3N0cjIgMjk0IHN0cmluZyBkZWYNCi9waWNzdHIzIDI5NCBz dHJpbmcgZGVmDQovcGljc3RyNCAyOTQgc3RyaW5nIGRlZg0KL3JlYWRkYXRhIHtjdXJyZW50Zmls ZSBleGNoIHJlYWRoZXhzdHJpbmcgcG9wfSBkZWYNCi9pbWFnZTIgbGV2ZWwyIHsvaW1hZ2UgbG9h ZCBkZWZ9IHt7YmVnaW4NCldpZHRoIEhlaWdodCBCaXRzUGVyQ29tcG9uZW50IEltYWdlTWF0cml4 DQpEZWNvZGUgbGVuZ3RoIDIgZXENCnsvRGF0YVNvdXJjZSBsb2FkIGltYWdlfSBpZg0KRGVjb2Rl IGxlbmd0aCA2IGVxDQp7RGF0YVNvdXJjZSAwIGdldCBEYXRhU291cmNlIDEgZ2V0IERhdGFTb3Vy Y2UgMiBnZXQNCnRydWUgMyBjb2xvcmltYWdlfSBpZg0KRGVjb2RlIGxlbmd0aCA4IGVxDQp7RGF0 YVNvdXJjZSAwIGdldCBEYXRhU291cmNlIDEgZ2V0DQpEYXRhU291cmNlIDIgZ2V0IERhdGFTb3Vy Y2UgMyBnZXQNCnRydWUgNCBjb2xvcmltYWdlfSBpZg0KZW5kfSBkZWZ9IGlmZWxzZQ0KL19pbWFn ZTIgbGV2ZWwyIHsvX2ltYWdlIGxvYWQgZGVmfSB7e2JlZ2luDQpXaWR0aCBIZWlnaHQgQml0c1Bl ckNvbXBvbmVudCBJbWFnZU1hdHJpeA0KL0RhdGFTb3VyY2UgbG9hZCBfaW1hZ2UgZW5kfSBkZWZ9 IGlmZWxzZQ0KL2JlZ2luaW1hZ2Ugew0KYmFuZCAwIGVxIGJhbmQgNCBlcSBvciBiYW5kIDUgZXEg b3INCntpbWFnZTJ9DQp7bmVnYXRpdmUge3twb3AgMH19IHt7cG9wIDF9fSBpZmVsc2UNCl9zZXR0 cmFuc2ZlciBfaW1hZ2UyfSBpZmVsc2UNCn0gZGVmDQoxMiBkaWN0IGJlZ2luDQovSW1hZ2VUeXBl IDEgZGVmDQovV2lkdGggY29scyBkZWYNCi9IZWlnaHQgcm93cyBkZWYNCi9JbWFnZU1hdHJpeCBb Y29scyAwIDAgcm93cyBuZWcgMCByb3dzXSBkZWYNCi9CaXRzUGVyQ29tcG9uZW50IDggZGVmDQpi YW5kIDAgZXENCnsvRGVjb2RlIFswIDEgMCAxIDAgMV0gZGVmDQovTXVsdGlwbGVEYXRhU291cmNl cyB0cnVlIGRlZg0KL0RhdGFTb3VyY2UgWw0Ke3BpY3N0cjEgcmVhZGRhdGF9DQp7cGljc3RyMiBy ZWFkZGF0YX0NCntwaWNzdHIzIHJlYWRkYXRhIHBpY3N0cjQgcmVhZGRhdGEgcG9wfQ0KXSBkZWZ9 DQp7L0RlY29kZSBbMCAxXSBkZWYNCi9EYXRhU291cmNlIHsNCnBpY3N0cjEgcmVhZGRhdGEgcG9w DQpwaWNzdHIyIHJlYWRkYXRhIHBvcA0KcGljc3RyMyByZWFkZGF0YSBwb3ANCnBpY3N0cjQgcmVh ZGRhdGENCn0gZGVmfQ0KaWZlbHNlDQpjdXJyZW50ZGljdCBlbmQNCiUlQmVnaW5CaW5hcnk6ICAg ICAxMjM3MTUNCmJlZ2luaW1hZ2UNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZBRTVBRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZC RTdCRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZERkJBRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkJDNzhGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZDMTA5ODRG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZDRDNBOURGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZFNjlDQ0VGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZDQzM2OUJGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGQzEzMDEyQzENCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZDRDU5NDFDREZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZFNkE3OTRFNkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZDQzU1M0JDQ0ZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGREYwOTAw MjFGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRTUzQTMzNERGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRjINCjlDNzU5RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZFNTM2MkI0OEZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRDUzMDAwMDA1MUZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGREQ1OTMzMzM3NEZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRUVBNzc1N0JCNUZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGREQ1NTJCMkINCjcwRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkYy MDAwMDAwOTlFRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkY0RDMzMzMzQUIxRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZBMzdCNjY4RUQ2RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkY0ODJCMjkz NUIwRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkUzMzAwNzAwMDAwOUQ1RkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkU5NTkNCjM5MzMzMzNBRERGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRjRBNzgzNjY2NjlDRUVG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRTg1NTMzMjkyOTM2RERGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYx NTEwNzA3MDkwMDFCRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkY0NzQzOTM5M0EzMzQ5RkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkY5QjU4MzgzOUMNCjc1OUZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRjM3MDMz MzMzNjJCNDRGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkY3NDYwNzA3M0MxMjAwNkJGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkY5NkIzOTM5NjM0MTMzODlGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZDQjM4MzgzQUQ5NDdC QzRGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkY5NjgzMzMzNUYzQjJCODYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG MzY3MDkNCjA5NTE3ODA3MTJCNEZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkY1ODUzQTNBNzQ5MzM5NDFDM0ZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZBQzE4RThFQjVDNzgzOTRFMUZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkY1ODIz NTM1NzA5MTMzM0JDMkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjZCMTIwNzUxRjE1MTAwMTFGM0ZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRjg5NDEzOTc0RjQNCjc0MzM0MUY1RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGQzQ5NDgzQjVG OUI1NzU5Q0ZBRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGODYzQjMzNzBGMzcwMkIzQ0Y1RkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRjc4MTIwNzVBRkZGRjI4MDAzMEZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjkzNDEzOTdCRkZGRjUzMzM1 OUZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkM3OTQ4M0JBRkZGRkE0NzUNCkFBRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjkx M0INCjMzNzhGRkZGNEYyQjU2RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRjhFMDkxMjVBRjNGRkQ1MTcwMDhFRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkE1M0E0MTdCRjVGRkRENDUzM0E1RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkQyOTQ5NEJB RkFGRkVFOUU4NEQyRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkEyMzUzQjc4RjVGRkRENDEyREEyRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZBNTFCMDk3Q0ZGRkYNCkZGQTUxMjEyRDBGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkI3NDkzQTk2RkZGRkZG Qjc0MTQxRDlGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkRCOUY5NENCRkZGRkZGREI5NDk0RUNGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkI2NDQzNTk0RkZGRkZGQjYzQjNCRDhGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZBNTE3MDk2N0ZGRkZGRkZGNjcwMDFC RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZCNzQ1M0E4NUZGRkZGRkZGODUNCjMzNDlGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZEQjlFOTQN CkMxRkZGRkZGRkZDMTdCOUZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkI2NDEzNTgyRkZGRkZGRkY4MjJCNDRGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRjc4Njc2QjZCNkI2Qjcy NzI3MjdDN0M3QzdDODQ4NDg0ODQ4RThFOEU4RThFOEU4RThFOEUNCjhFOEU4RThFOEU4RThFOEU4 RThFOEU4RThFOEU4RThFOEU4RThFOEU4RThFOEU4RThFOEU4RThFOEU4RThFOEUNCjhFOEU4RThF OEU4RThFOEU4RTExMDk0Njg0ODQ4NDg0ODQzMDAwM0M4RThFOUE4RThFOEU4RThFOEU4RThFOEUN CjhFOEU4QzY3RTBGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRjkzODU4OTg5ODk4OThFOEU4RTk2OTY5Njk2OUQ5RDlEOURB NUE1QTUNCkE1QTVBNUE1QTVBNUE1QTVBNUE1QTVBNUE1QTVBNUE1QTVBNUE1QTVBNUE1QTVBNUE1 QTVBNUE1QTVBNUE1QTUNCkE1QTVBNUE1QTVBNUE1QTVBNUE1QTVBNUE1QTVBNTQxM0E2QjlEOUQ5 RDlEOUQ1OTMzNjNBNUE1QUVBNUE1QTUNCkE1QTVBNUE1QTVBNUE1QTVBMzg1RTZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkM3QzFDNEM0QzRDNEM1QzVDNUNCQ0JDQkNCQ0UNCkNFQ0VDRUQyRDJEMkQyRDJEMkQyRDJEMkQy RDJEMkQyRDJEMkQyRDJEMkQyRDJEMkQyRDJEMkQyRDJEMkQyRDINCkQyRDJEMkQyRDJEMkQyRDJE MkQyRDJEMkQyRDJEMkQyRDJEMkQyRDJEMjlDOTRCM0NFQ0VDRUNFQ0VBQTdCQUQNCkQyRDJEN0Qy RDJEMkQyRDJEMkQyRDJEMkQyRDJDRkMxRjNGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjkxODI4Njg2ODY4NjhDOEMNCjhD OTQ5NDk0OTQ5QjlCOUI5QkEyQTJBMkEyQTJBMkEyQTJBMkEyQTJBMkEyQTJBMkEyQTJBMkEyQTJB MkEyQTINCkEyQTJBMkEyQTJBMkEyQTJBMkEyQTJBMkEyQTJBMkEyQTJBMkEyQTJBMkEyQTJBMkEy QTJBMjNDMzU2ODlCOUINCjlCOUI5QjU2MkI1RkEyQTJBREEyQTJBMkEyQTJBMkEyQTJBMkEyQTJB MTgyRTZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRjMwMjgNCjIwMjAyMDIwMTcxNzE3MTExMTA5MDkwOTA5MDkwOTAwMDAw MDA5MDkwOTA5MDkwMDAwMDAwOTA5MDkwOTA5MDkNCjA5MDkwOTA5MDkwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDANCjAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwOTQ2REZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGNTk1 MzRENEQ0RDRENDU0NTQ1NDE0MTNBM0EzQTNBM0EzQTMzMzMzMzNBM0EzQTNBM0EzMzMzMzMNCjNB M0EzQTNBM0EzQTNBM0EzQTNBM0EzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMz MzMzMzMNCjMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMzMz MzMzMzMzMzMzMzMzMzMNCjNBNkJFNUZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGQUFBNEEzQTNBM0EzOUU5RTlFOUM5QzlD OUM5QzlDOUM5Qzk5OTk5OTlDOUMNCjlDOUM5Qzk5OTk5OTk0OTQ5NDk0OTQ5NDk0OTQ5NDk0OTQ4 RDhEOEQ4RDhEOEQ4RDhEOEQ4RDhEOEQ4RDhEODQNCjg0ODQ4NDg0ODQ4NDg0ODQ4NDg0ODQ4NDdC N0I4RDg0ODQ4NDg0ODQ4NDdCNzU3QjdCN0I3QjdCN0I3QjdCN0INCjdCN0I3QjdCN0I4RDlDQjNG MkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGNTY0RjQ4NDg0ODQ4NDE0MTQxM0MzQzM2MzYzNjM2MzYNCjM2MkYyRjJGMzYz NjM2MzYzNjJGMkYyRjM1MzUzNTM1MzUzNTM1MzUzNTM1MzUyRTJFMkUyRTJFMkUyRTJFMkUNCjJF MkUyRTJFMkUyRDJEMkQyRDJEMkQyRDJEMkQyRDJEMkQyRDJCMkIyRTJEMkQyRDJEMkQyRDJCMkIy QjJCMkINCjJCMkIyQjJCMkIyQjJCMkIyQjJCMkIyRTM2NjhFNUZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRjFGMUYxRjFFMEUwRTBFMEQwRDBEMEMx QzFDMUMxQjRCNEI0QTVBNTlBOUUNCjhFOEU4RThFN0M3QzdDNzI3MjcyNzI1QTQ2NDY0NjNDM0Mz QzMwMzAzMDMwMUIwOTA5MzAyMTFCMUIxQjFCMTcNCjExMDkwMDE3MUIyMTIxMjEyMTIxMTIwOTAw MDAwMDAwMjE2N0Q1RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRjRGNEY0RjRFNkU2RTZFNkQ5RDlEOUNEQ0RDRENEQzMNCkMzQzNCN0I3QUVC MUE1QTVBNUE1OTY5Njk2OEU4RThFOEU3QjZCNkI2QjYzNjM2MzU5NTk1OTU5NDkzQTNBNTkNCjRE NDk0OTQ5NDk0NTQxM0EzMzQ1NDk0RDRENEQ0RDRENDEzQTMzMzMzMzMzNEQ4NURERkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjlGOUY5RjlG M0YzRjNGM0VDRUMNCkVDRTZFNkU2RTZFMUUxRTFEQkRCRDdENkQyRDJEMkQyQ0JDQkNCQzVDNUM1 QzVCQUIzQjNCM0FEQURBREFBQUENCkFBQUE5RjlDOTRBNzlGOUY5RjlGOUY5RTlDOEU5OTlFOUY5 RjlGOUY5RjlGOTQ5NDhENjY2NjdCOUZDMUVFRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjNGM0YzRjMNCkU2RTZFNkU2RDhEOEQ4Q0NDQ0ND Q0NDMkMyQzJCNkI2QURCMEEyQTJBMkEyOTQ5NDk0OEM4QzhDOEM3ODY4NjgNCjY4NUY1RjVGNTY1 NjU2NTY0NDM2MzU1NTQ4NDQ0NDQ0NDQ0MTNDMzUyRjQxNDQ0ODQ4NDg0ODQ4M0IzNTJFMjkNCjI5 MkI0ODgyRERGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRTcwOTA5OENGRkZGRkZGRkZG RkZGRjg0MDcxMUZGRkZGM0YxRjENCkYxQzEzQzEyMDAwNzE3NkJENUZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRUMzQTNBQTNGRkZGRkZGRkZGRkZGRjlEMzkNCjQxRkZGRkY1RjRG NEY0Q0Q2MzQxMzMzOTQ1ODlEREZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjU5 Qzk0Q0ZGRkZGRkYNCkZGRkZGRkZGQ0U4MzlDRkZGRkZBRjlGOUY5RTZBRDk0NzU4MzlFQzRFRUZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRUINCjM2MzVBMUZGRkZGRkZGRkZGRkZG OUIzMzNDRkZGRkY1RjNGM0YzQ0M1RjNCMkIzMzQxODZEREZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGREYzMDA5OUVGRkZGRkZGRkZGRkZGRkZGNDYwMDVBRkZGRkZGRkZENTVBMjEw MDA3MDA3Q0U3RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRTU1OTNBQjFG RkZGRkZGRkZGRkZGRkZGNkIzMzdCRkZGRkZGRkZERDdCNEQNCjMzMzkzMzk2RUNGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjJBNzk0RDZGRkZGRkZGRkZGRkZGRkZGQjM4NEJB RkYNCkZGRkZGRkVFQkE5RjdCODM5OUNCRjVGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRTU1NTM1QjBGRkZGRkZGRkZGRkYNCkZGRkY2ODJENzhGRkZGRkZGRkRENzg0ODJCMzMy Rjk0RUJGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkU2Q0NFNkZGRkZGRkZGRkZGRkZGRkZGRkZGRTZDQ0YyRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYxM0MwMDhDRkYNCkZGRkZG RkZGRkZGRkZGRkYwOTA5QjRGRkZGRTc3MjIxMDcwNzIxNzJGMUZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkU2Q0NFNkZGRkZG RkZGRkZGRkZGRkZGRkZGRTZDQ0YyRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRjQ2MzMzQTNGRkZGRkZGRkZGRkZGRkZGRkYzQTNBQzNGRkZG RUM4RTREMzkzOTREOEVGNEZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkU2Q0NFNkZGRkZGRkZGRkZGRkZGRkZGRkZGRTYNCkND RjJGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RjlBRDk5Q0ZGRkZGRkZGRkZGRkZGRkZGRkY5QzhFRTFGRkZGRjVDNTlGODM4MzlGQzUNCkY5RkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkU2Q0NFNkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZFNkNDRjJGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjM1RjJGQTFGRkZGRkZGRkZGRkZG RkZGRkYzNjM1QzJGRkZGRUINCjhDNDgzMzMzNDg4Q0YzRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGQ0MzMzMzNzRGRkZGRkZGRkZGRkZGRkZGRDk2NjMzMzMNCjMzNjZGMkZGRkZG RkZGRkZGRkQ5NUEzMzMzMzM2NkYyRkZGRkZGRkZGRkZGNjYzMzMzRTY4QzMzMzM5OUZGRkYNCkZG RkZGRkQ5MzMzMzY2RkY0MDMzMzNGRkZGRkZGRkZGRkZCRjMzMzMzMzMzMzNCRkZGRkZGRkZGRkZG RjVBMzMNCjMzMzMzMzVBRkZGRkZGRkZGRkZGQkYzMzMzMzMzMzRDOTlGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZDQzMzMzMNCjMzMzNGRjgwMzMzMzMzOENGRkZGRkZGRkZGRkZGRjk5MzMzMzMzNjZG RkZGRkZGRkZGRkZGRkZGNjYzMzMzMzMNCjMzMzM4Q0ZGRkZGRkZGRkZGRkIzMzMzMzMzMzMzMzMz Q0NGRkZGRkZGRkZGRDkzMzMzNjZGRkZGRkZGRkZGRkYNCkQ5MzMzMzMzOTlGRjMzMzNCM0ZGRkZG RkZGRkZGRkZGRkZGRkU3MzAxMTlFRkZGRkZGRkZGRkZGRkZGRkZGREYNCjA5MTFGM0ZGOEUxMTA3 MDcyODdDRTdGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGQ0MzMzMzNzRG RkZGRkZGRkZGRkYNCkZGRkZEOTY2MzMzMzMzNjZGMkZGRkZGRkZGRkZGRkQ5NUEzMzMzMzM2NkYy RkZGRkZGRkZGRkZGNjYzMzMzRTYNCjhDMzMzMzk5RkZGRkZGRkZGRkQ5MzMzMzY2RkY0MDMzMzNG RkZGRkZGRkZGRkZCRjMzMzMzMzMzMzNCRkZGRkYNCkZGRkZGRkZGNUEzMzMzMzMzMzVBRkZGRkZG RkZGRkZGQkYzMzMzMzMzMzRDOTlGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkNDMzMzMzMzMzNG RjgwMzMzMzMzOENGRkZGRkZGRkZGRkZGRjk5MzMzMzMzNjZGRkZGRkZGRkZGRkYNCkZGRkY2NjMz MzMzMzMzMzM4Q0ZGRkZGRkZGRkZGRkIzMzMzMzMzMzMzMzMzQ0NGRkZGRkZGRkZGRDkzMzMzNjYN CkZGRkZGRkZGRkZGRkQ5MzMzMzMzOTlGRjMzMzNCM0ZGRkZGRkZGRkZGRkZGRkZGRkVDNTk0MUIx RkZGRkZGRkYNCkZGRkZGRkZGRkZFNTNBNDFGNUZGQTU0MTM5Mzk1Mzk2RUNGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGQ0MzMzMzNzQNCkZGRkZGRkZGRkZGRkZGRkZEOTY2 MzMzMzMzNjZGMkZGRkZGRkZGRkZGRkQ5NUEzMzMzMzM2NkYyRkZGRkZGRkYNCkZGRkY2NjMzMzNF NjhDMzMzMzk5RkZGRkZGRkZGRkQ5MzMzMzY2RkY0MDMzMzNGRkZGRkZGRkZGRkZCRjMzMzMNCjMz MzMzM0JGRkZGRkZGRkZGRkZGNUEzMzMzMzMzMzVBRkZGRkZGRkZGRkZGQkYzMzMzMzMzMzRDOTlG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkNDMzMzMzMzMzNGRjgwMzMzMzMzOENGRkZGRkZGRkZG RkZGRjk5MzMzMzMzNjYNCkZGRkZGRkZGRkZGRkZGRkY2NjMzMzMzMzMzMzM4Q0ZGRkZGRkZGRkZG RkIzMzMzMzMzMzMzMzMzQ0NGRkZGRkYNCkZGRkZEOTMzMzM2NkZGRkZGRkZGRkZGRkQ5MzMzMzMz OTlGRjMzMzNCM0ZGRkZGRkZGRkZGRkZGRkZGRkY1QTcNCjlDRDZGRkZGRkZGRkZGRkZGRkZGRkZG MjlDOUNGQUZGRDI5QzgzODNBNENCRjVGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZDQzMzMzM3NEZGRkZGRkZGRkZGRkZGRkZEOTY2MzMzMzMzNjZGMkZGRkZGRkZGRkZG RkQ5NUEzMzMzMzMNCjY2RjJGRkZGRkZGRkZGRkY2NjMzMzNFNjhDMzMzMzk5RkZGRkZGRkZGRkQ5 MzMzMzY2RkY0MDMzMzNGRkZGRkYNCkZGRkZGRkJGMzMzMzMzMzMzM0JGRkZGRkZGRkZGRkZGNUEz MzMzMzMzMzVBRkZGRkZGRkZGRkZGQkYzMzMzMzMNCjMzNEM5OUZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkNDMzMzMzMzMzNGRjgwMzMzMzMzOENGRkZGRkZGRkZGRkYNCkZGOTkzMzMzMzM2NkZGRkZG RkZGRkZGRkZGRkY2NjMzMzMzMzMzMzM4Q0ZGRkZGRkZGRkZGRkIzMzMzMzMzMzMNCjMzMzNDQ0ZG RkZGRkZGRkZEOTMzMzM2NkZGRkZGRkZGRkZGRkQ5MzMzMzMzOTlGRjMzMzNCM0ZGRkZGRkZGRkYN CkZGRkZGRkZGRUI1NTNDQjBGRkZGRkZGRkZGRkZGRkZGRkZFNTM2M0NGNUZGQTIzQzMzMzM0Rjk0 RUJGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkY5OTMzMzM5OUZGRkZG RkZGRkZGRkZGRDk0MDMzNDA0QzMzMzNBNUZGRkZGRkZGRkYNCkQ5NDAzMzQwNEMzMzMzQTVGRkZG RkZGRkZGRkYzMzMzNDBDQzMzMzM3NEZGRkZGRkZGRkZGRkIzMzMzMzhDRDkNCjMzMzM2NkZGRkZG RkZGRkZGRjhDMzMzMzMzMzMzM0U2RkZGRkZGRkZGRkZGMzMzMzMzMzMzMzgwRkZGRkZGRkYNCkZG RkY5OTMzMzM1QTQwMzMzM0IzRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjk5MzMzMzMzMzNGMjQwMzMz MzMzQjMNCkZGRkZGRkZGRkZGRkYyNDAzMzgwMzM2NkZGRkZGRkZGRkZGRkZGRkY0MDMzNDA2NjMz MzMzM0ZGRkZGRkZGRkYNCkZGODAzMzMzMzMzMzMzMzNGRkZGRkZGRkZGRkZBNTMzMzM5OUZGRkZG RkZGRkZGRkIzMzMzMzMzNjZDQzMzMzMNCkU2RkZGRkZGRkZGRkZGRkZGRkYxNDYwMDlFRkZGRkZG RkZGRkZGRkZGRkZGRkY5QTA5MzBBNTE3MDkwNzFCODQNCkU3RkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkY5OTMzMzM5OUZGRkZGRkZGRkZGRkZGRDk0MDMzNDA0QzMz MzMNCkE1RkZGRkZGRkZGRkQ5NDAzMzQwNEMzMzMzQTVGRkZGRkZGRkZGRkYzMzMzNDBDQzMzMzM3 NEZGRkZGRkZGRkYNCkZGQjMzMzMzOENEOTMzMzM2NkZGRkZGRkZGRkZGRjhDMzMzMzMzMzMzM0U2 RkZGRkZGRkZGRkZGMzMzMzMzMzMNCjMzODBGRkZGRkZGRkZGRkY5OTMzMzM1QTQwMzMzM0IzRkZG RkZGRkZGRkZGRkZGRkZGRkZGRjk5MzMzMzMzMzMNCkYyNDAzMzMzMzNCM0ZGRkZGRkZGRkZGRkYy NDAzMzgwMzM2NkZGRkZGRkZGRkZGRkZGRkY0MDMzNDA2NjMzMzMNCjMzRkZGRkZGRkZGRkZGODAz MzMzMzMzMzMzMzNGRkZGRkZGRkZGRkZBNTMzMzM5OUZGRkZGRkZGRkZGRkIzMzMNCjMzMzM2NkND MzMzM0U2RkZGRkZGRkZGRkZGRkZGRkY0NkIzM0IxRkZGRkZGRkZGRkZGRkZGRkZGRkZBRTNBNTkN CkI3NDUzQTM5NDk5REVDRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkY5OTMzMzM5OUZGRkZGRkZGRkZGRkZGRDkNCjQwMzM0MDRDMzMzM0E1RkZGRkZGRkZGRkQ5NDAz MzQwNEMzMzMzQTVGRkZGRkZGRkZGRkYzMzMzNDBDQzMzMzMNCjc0RkZGRkZGRkZGRkZGQjMzMzMz OENEOTMzMzM2NkZGRkZGRkZGRkZGRjhDMzMzMzMzMzMzM0U2RkZGRkZGRkYNCkZGRkYzMzMzMzMz MzMzODBGRkZGRkZGRkZGRkY5OTMzMzM1QTQwMzMzM0IzRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG OTkzMzMzMzMzM0YyNDAzMzMzMzNCM0ZGRkZGRkZGRkZGRkYyNDAzMzgwMzM2NkZGRkZGRkZGRkZG RkZGRkYNCjQwMzM0MDY2MzMzMzMzRkZGRkZGRkZGRkZGODAzMzMzMzMzMzMzMzNGRkZGRkZGRkZG RkZBNTMzMzM5OUZGRkYNCkZGRkZGRkZGQjMzMzMzMzM2NkNDMzMzM0U2RkZGRkZGRkZGRkZGRkZG RkY5QjM5OUQ2RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkQ3OTRBN0RCOUU4RTgzOUZDRUY1RkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkY5OTMzMzM5OUZGRkYNCkZGRkZG RkZGRkZEOTQwMzM0MDRDMzMzM0E1RkZGRkZGRkZGRkQ5NDAzMzQwNEMzMzMzQTVGRkZGRkZGRkZG RkYNCjMzMzM0MENDMzMzMzc0RkZGRkZGRkZGRkZGQjMzMzMzOENEOTMzMzM2NkZGRkZGRkZGRkZG RjhDMzMzMzMzMzMNCjMzRTZGRkZGRkZGRkZGRkYzMzMzMzMzMzMzODBGRkZGRkZGRkZGRkY5OTMz MzM1QTQwMzMzM0IzRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGOTkzMzMzMzMzM0YyNDAzMzMzMzNC M0ZGRkZGRkZGRkZGRkYyNDAzMzgwMzM2NkZGRkYNCkZGRkZGRkZGRkZGRjQwMzM0MDY2MzMzMzMz RkZGRkZGRkZGRkZGODAzMzMzMzMzMzMzMzNGRkZGRkZGRkZGRkYNCkE1MzMzMzk5RkZGRkZGRkZG RkZGQjMzMzMzMzM2NkNDMzMzM0U2RkZGRkZGRkZGRkZGRkZGRkYzNjgyRkIwRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkFEMzU1NUI2NDEzNTMzNDQ5QkVCRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCjc0MzMzM0NDRkZGRkZGRkZGRkZGRkY2NjMzMzNCRkNDMzMzMzY2 RkZGRkZGRkZGRjY2MzMzM0NDRDk2NjY2QjMNCkZGRkZGRkZGRkZEOTMzMzM2NjQwMzM0Q0YyRkZG RkZGRkZGRkZGOEMzMzMzNjY4MDMzMzM4Q0ZGRkZGRkZGRkYNCkZGNjYzMzMzQkZDQ0U2RkZGRkZG RkZGRkZGQ0MzMzMzNzRDQ0NDRkZGRkZGRkZGRkZGRkY2NjMzMzNFNjk5MzMNCjMzOTlGRkZGRkZG RkZGRkZGRkZGRkZGRkZGNzQzMzVBMzM0Q0IzMzM0QzMzMzNEOUZGRkZGRkZGRkZGRjk5MzMNCjRD QjMzMzQwRkZGRkZGRkZGRkZGRkZEOTMzMzM2NkU2MzMzMzgwRkZGRkZGRkZGRkZGRkZGRjMzMzMz M0ZGRkYNCkZGRkZGRkZGRkZGRjgwMzMzM0JGRkZGRkZGRkZGRkZGODAzMzMzMzM2Njk5MzM0MEZG RkZGRkZGRkZGRkZGRkYNCkZGNTEwOUI0RkZGRkZGRkZGRkZGRkZGRkZGRkZGRjZCMDAyODEyMDkw OThDRjNGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRjc0 MzMzM0NDRkZGRkZGRkZGRkZGRkY2NjMzMzNCRkNDMzMzMzY2RkZGRkZGRkZGRjY2MzMNCjMzQ0NE OTY2NjZCM0ZGRkZGRkZGRkZEOTMzMzM2NjQwMzM0Q0YyRkZGRkZGRkZGRkZGOEMzMzMzNjY4MDMz MzMNCjhDRkZGRkZGRkZGRkZGNjYzMzMzQkZDQ0U2RkZGRkZGRkZGRkZGQ0MzMzMzNzRDQ0NDRkZG RkZGRkZGRkZGRkYNCjY2MzMzM0U2OTkzMzMzOTlGRkZGRkZGRkZGRkZGRkZGRkZGRkZGNzQzMzVB MzM0Q0IzMzM0QzMzMzNEOUZGRkYNCkZGRkZGRkZGOTkzMzRDQjMzMzQwRkZGRkZGRkZGRkZGRkZE OTMzMzM2NkU2MzMzMzgwRkZGRkZGRkZGRkZGRkYNCkZGMzMzMzMzRkZGRkZGRkZGRkZGRkZGRjgw MzMzM0JGRkZGRkZGRkZGRkZGODAzMzMzMzM2Njk5MzM0MEZGRkYNCkZGRkZGRkZGRkZGRkZGNzQz QUMzRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjg5MzM1MzQxM0EzQUEzRjVGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjc0MzMzM0NDRkZGRkZGRkZGRkZGRkY2 NjMzMzNCRkNDMzMzMzY2RkYNCkZGRkZGRkZGNjYzMzMzQ0NEOTY2NjZCM0ZGRkZGRkZGRkZEOTMz MzM2NjQwMzM0Q0YyRkZGRkZGRkZGRkZGOEMNCjMzMzM2NjgwMzMzMzhDRkZGRkZGRkZGRkZGNjYz MzMzQkZDQ0U2RkZGRkZGRkZGRkZGQ0MzMzMzNzRDQ0NDRkYNCkZGRkZGRkZGRkZGRjY2MzMzM0U2 OTkzMzMzOTlGRkZGRkZGRkZGRkZGRkZGRkZGRkZGNzQzMzVBMzM0Q0IzMzMNCjRDMzMzM0Q5RkZG RkZGRkZGRkZGOTkzMzRDQjMzMzQwRkZGRkZGRkZGRkZGRkZEOTMzMzM2NkU2MzMzMzgwRkYNCkZG RkZGRkZGRkZGRkZGMzMzMzMzRkZGRkZGRkZGRkZGRkZGRjgwMzMzM0JGRkZGRkZGRkZGRkZGODAz MzMzMzMNCjY2OTkzMzQwRkZGRkZGRkZGRkZGRkZGRkZGQjU5Q0UxRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkM0OERBNDk0OEUNCjlDQ0ZGQUZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRjc0MzMzM0NDRkZGRkZGRkZGRkZGRkY2NjMzMzMNCkJGQ0MzMzMzNjZGRkZG RkZGRkZGNjYzMzMzQ0NEOTY2NjZCM0ZGRkZGRkZGRkZEOTMzMzM2NjQwMzM0Q0YyRkYNCkZGRkZG RkZGRkY4QzMzMzM2NjgwMzMzMzhDRkZGRkZGRkZGRkZGNjYzMzMzQkZDQ0U2RkZGRkZGRkZGRkZG Q0MNCjMzMzM3NENDQ0NGRkZGRkZGRkZGRkZGRjY2MzMzM0U2OTkzMzMzOTlGRkZGRkZGRkZGRkZG RkZGRkZGRkZGNzQNCjMzNUEzMzRDQjMzMzRDMzMzM0Q5RkZGRkZGRkZGRkZGOTkzMzRDQjMzMzQw RkZGRkZGRkZGRkZGRkZEOTMzMzMNCjY2RTYzMzMzODBGRkZGRkZGRkZGRkZGRkZGMzMzMzMzRkZG RkZGRkZGRkZGRkZGRjgwMzMzM0JGRkZGRkZGRkYNCkZGRkY4MDMzMzMzMzY2OTkzMzQwRkZGRkZG RkZGRkZGRkZGRkZGNzAzNkMyRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGODYyRTRGM0IzNTM2QTFG NUZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjRDMzMzM0Yy RkZGRkZGRkYNCkZGRkZGMjMzMzMzM0ZGOTkzMzMzOENGRkZGRkZGRkU2MzMzMzMzRkZGRkZGRkZG RkZGRkZGRkZGRkZBNTMzMzMNCjMzMzMzM0JGRkZGRkZGRkZGRkZGRkY1QTMzMzMzMzMzMzMzM0Iz RkZGRkZGRkZGRkZGMzMzMzMzMzMzMzk5RkYNCkZGRkZGRkZGRkY5OTMzMzMzMzMzMzNGRkZGRkZG RkZGRkZGRjQwMzM0MEZGOEMzMzMzOTlGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkY0MDMzOEMzMzY2 NUEzMzc0MzM0MEZGRkZGRkZGRkZGRkU2NDAzM0E1NjYzMzMzRkZGRkZGRkYNCkZGRkZGRkIzMzMz MzMzMzMzMzgwRjJGRkZGRkZGRkZGRkZGRkQ5MzMzMzY2RkZGRkZGRkZGRkZGRkZGRjVBMzMNCjMz RTZGRkZGRkZGRkZGRkY1QTMzNUEzMzMzNzQzMzY2RkZGRkZGRkZGRkZGRkZGNzUxMDBBNUZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkI0MjgwMDAwMjE4Q0ZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjRDMzMNCjMzRjJGRkZGRkZGRkZGRkZGMjMzMzMz M0ZGOTkzMzMzOENGRkZGRkZGRkU2MzMzMzMzRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkE1MzMzMzMz MzMzM0JGRkZGRkZGRkZGRkZGRkY1QTMzMzMzMzMzMzMzM0IzRkZGRkZGRkZGRkZGMzMNCjMzMzMz MzMzOTlGRkZGRkZGRkZGRkY5OTMzMzMzMzMzMzNGRkZGRkZGRkZGRkZGRjQwMzM0MEZGOEMzMzMz OTkNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkY0MDMzOEMzMzY2NUEzMzc0MzM0MEZGRkZGRkZGRkZG RkU2NDAzM0E1NjYNCjMzMzNGRkZGRkZGRkZGRkZGRkIzMzMzMzMzMzMzMzgwRjJGRkZGRkZGRkZG RkZGRkQ5MzMzMzY2RkZGRkZGRkYNCkZGRkZGRkZGNUEzMzMzRTZGRkZGRkZGRkZGRkY1QTMzNUEz MzMzNzQzMzY2RkZGRkZGRkZGRkZGRkZGOTc0MzMNCkI3RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkMz NTMzMzMzNERBM0ZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGNEMzMzMzRjJGRkZGRkZGRkZGRkZGMjMzMzMzM0ZGOTkzMzMzOENGRkZGRkZGRkU2 MzMzMzMzRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkE1MzMzMzMzMzMzM0JGRkZGRkZGRkZGRkZGRkY1 QTMzMzMzMzMzMzMzM0IzRkYNCkZGRkZGRkZGRkYzMzMzMzMzMzMzOTlGRkZGRkZGRkZGRkY5OTMz MzMzMzMzMzNGRkZGRkZGRkZGRkZGRjQwMzMNCjQwRkY4QzMzMzM5OUZGRkZGRkZGRkZGRkZGRkZG RkZGRkY0MDMzOEMzMzY2NUEzMzc0MzM0MEZGRkZGRkZGRkYNCkZGRTY0MDMzQTU2NjMzMzNGRkZG RkZGRkZGRkZGRkIzMzMzMzMzMzMzMzgwRjJGRkZGRkZGRkZGRkZGRkQ5MzMNCjMzNjZGRkZGRkZG RkZGRkZGRkZGNUEzMzMzRTZGRkZGRkZGRkZGRkY1QTMzNUEzMzMzNzQzMzY2RkZGRkZGRkYNCkZG RkZGRkZDQjU5OURCRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkUxQTQ4NDhEOUZDRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGNEMzMzMzRjJGRkZG RkZGRkZGRkZGMjMzMzMzM0ZGOTkzMzMzOENGRkZGRkYNCkZGRTYzMzMzMzNGRkZGRkZGRkZGRkZG RkZGRkZGRkE1MzMzMzMzMzMzM0JGRkZGRkZGRkZGRkZGRkY1QTMzMzMNCjMzMzMzMzMzQjNGRkZG RkZGRkZGRkYzMzMzMzMzMzMzOTlGRkZGRkZGRkZGRkY5OTMzMzMzMzMzMzNGRkZGRkYNCkZGRkZG RkZGNDAzMzQwRkY4QzMzMzM5OUZGRkZGRkZGRkZGRkZGRkZGRkZGRkY0MDMzOEMzMzY2NUEzMzc0 MzMNCjQwRkZGRkZGRkZGRkZGRTY0MDMzQTU2NjMzMzNGRkZGRkZGRkZGRkZGRkIzMzMzMzMzMzMz MzgwRjJGRkZGRkYNCkZGRkZGRkZGRDkzMzMzNjZGRkZGRkZGRkZGRkZGRkZGNUEzMzMzRTZGRkZG RkZGRkZGRkY1QTMzNUEzMzMzNzQNCjMzNjZGRkZGRkZGRkZGRkZGRkY5NzAyRkI2RkZGRkZGRkZG RkZGRkZGRkZGRkZGRkMyNEYyRDJFNDhBMUZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkU2MzMzMzVBRkZGRkZGRkZGRkZGRkZDQzMzMzM2NkZGNzQN CjMzMzNCM0ZGRkZGRkZGQ0MzMzMzNjZGRkNDQ0NDQ0ZGRkZGRkZGRkZGRjgwMzMzMzY2MzMzMzhD RkZGRkZGRkYNCkZGRkZGRjMzMzM0MDY2MzMzMzMzRDlGRkZGRkZGRkZGRDkzMzMzNEM2NjY2RDlG RkZGRkZGRkZGRkY3NDMzMzMNCjY2NjY4Q0ZGRkZGRkZGRkZGRkQ5MzMzMzY2RkY1QTMzMzNEOUZG RkZGRkZGRkZGRkZGRkZGRkZGRTYzMzMzQTUNCjMzNDAzMzY2NjYzMzY2RkZGRkZGRkZGRkZGODAz MzMzOEM0QzMzMzNFNkZGRkZGRkZGRkZGRjhDMzMzMzVBMzMNCjMzMzNGRkZGRkZGRkZGRkZGRkZG QTUzMzMzOTlGRkZGRkZGRkZGRkZGRkYyMzMzMzQwRkZGRkZGRkZGRkZGRkYNCjMzMzNCMzMzMzM0 QzMzOTlGRkZGRkZGRkZGRkZGRjY3MDBCNEZGRkZGRkZGRkZGRkZGRkZGRkZGRDA1MTEyMDANCjFC OEVGMUZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkU2MzMzMzVBRkZGRkZGRkZGRkZGRkYNCkNDMzMzMzY2RkY3NDMzMzNCM0ZGRkZGRkZGQ0MzMzMz NjZGRkNDQ0NDQ0ZGRkZGRkZGRkZGRjgwMzMzMzY2MzMNCjMzOENGRkZGRkZGRkZGRkZGRjMzMzM0 MDY2MzMzMzMzRDlGRkZGRkZGRkZGRDkzMzMzNEM2NjY2RDlGRkZGRkYNCkZGRkZGRjc0MzMzMzY2 NjY4Q0ZGRkZGRkZGRkZGRkQ5MzMzMzY2RkY1QTMzMzNEOUZGRkZGRkZGRkZGRkZGRkYNCkZGRkZF NjMzMzNBNTMzNDAzMzY2NjYzMzY2RkZGRkZGRkZGRkZGODAzMzMzOEM0QzMzMzNFNkZGRkZGRkZG RkYNCkZGOEMzMzMzNUEzMzMzMzNGRkZGRkZGRkZGRkZGRkZGQTUzMzMzOTlGRkZGRkZGRkZGRkZG RkYyMzMzMzQwRkYNCkZGRkZGRkZGRkZGRjMzMzNCMzMzMzM0QzMzOTlGRkZGRkZGRkZGRkZGRjg1 MzNDM0ZGRkZGRkZGRkZGRkZGRkYNCkZGRkZEOTc0NDEzMzQ5QTVGNEZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkU2MzMzMzVBRkYNCkZGRkZGRkZG RkZGRkNDMzMzMzY2RkY3NDMzMzNCM0ZGRkZGRkZGQ0MzMzMzNjZGRkNDQ0NDQ0ZGRkZGRkZGRkYN CkZGODAzMzMzNjYzMzMzOENGRkZGRkZGRkZGRkZGRjMzMzM0MDY2MzMzMzMzRDlGRkZGRkZGRkZG RDkzMzMzNEMNCjY2NjZEOUZGRkZGRkZGRkZGRjc0MzMzMzY2NjY4Q0ZGRkZGRkZGRkZGRkQ5MzMz MzY2RkY1QTMzMzNEOUZGRkYNCkZGRkZGRkZGRkZGRkZGRkZFNjMzMzNBNTMzNDAzMzY2NjYzMzY2 RkZGRkZGRkZGRkZGODAzMzMzOEM0QzMzMzMNCkU2RkZGRkZGRkZGRkZGOEMzMzMzNUEzMzMzMzNG RkZGRkZGRkZGRkZGRkZGQTUzMzMzOTlGRkZGRkZGRkZGRkYNCkZGRjIzMzMzNDBGRkZGRkZGRkZG RkZGRjMzMzNCMzMzMzM0QzMzOTlGRkZGRkZGRkZGRkZGRkMxOTlFMUZGRkYNCkZGRkZGRkZGRkZG RkZGRkZFQ0I1OTQ3QjlGRDJGOUZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRTYzMzMzNUFGRkZGRkZGRkZGRkZGRkNDMzMzMzY2RkY3NDMzMzNC M0ZGRkZGRkZGQ0MzMzMzNjZGRkNDQ0MNCkNDRkZGRkZGRkZGRkZGODAzMzMzNjYzMzMzOENGRkZG RkZGRkZGRkZGRjMzMzM0MDY2MzMzMzMzRDlGRkZGRkYNCkZGRkZEOTMzMzM0QzY2NjZEOUZGRkZG RkZGRkZGRjc0MzMzMzY2NjY4Q0ZGRkZGRkZGRkZGRkQ5MzMzMzY2RkYNCjVBMzMzM0Q5RkZGRkZG RkZGRkZGRkZGRkZGRkZFNjMzMzNBNTMzNDAzMzY2NjYzMzY2RkZGRkZGRkZGRkZGODANCjMzMzM4 QzRDMzMzM0U2RkZGRkZGRkZGRkZGOEMzMzMzNUEzMzMzMzNGRkZGRkZGRkZGRkZGRkZGQTUzMzMz OTkNCkZGRkZGRkZGRkZGRkZGRjIzMzMzNDBGRkZGRkZGRkZGRkZGRjMzMzNCMzMzMzM0QzMzOTlG RkZGRkZGRkZGRkYNCkZGODIyRkMyRkZGRkZGRkZGRkZGRkZGRkZGRkZEODcwM0IyQjQ0QTJGM0ZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGQkYz MzMzNEM5OTk5RTZGRkZGRkZGRkQ5MzMzMzRDQ0MzMzMzNUFGRkZGRkZGRkZGQ0MNCjMzMzM0Q0Iz MzMzMzgwRkZGRkZGRkZGRkZGNUEzMzMzQ0MzMzMzNENGRkZGRkZGRkZGRkZDQzMzMzM2NkZGMzMN CjMzNDBGRkZGRkZGRkZGRkZBNTMzMzM2Njk5OTlFNkZGRkZGRkZGRkZGRjRDMzMzMzk5OTlCM0ZG RkZGRkZGRkYNCkZGQjMzMzMzODA4QzMzMzM3NEZGRkZGRkZGRkZGRkZGRkZGRkZGRkZCRjMzMzNB NTMzMzMzM0IzMzMzMzk5RkYNCkZGRkZGRkZGRTYzMzMzMzMzMzMzMzMzM0NDRkZGRkZGRkZGRkZG NUEzMzMzRjI2NjMzMzNGRkZGRkZGRkZGRkYNCkZGRkY4MDMzMzNCRkZGRkZGRkZGRkZGRkZGQ0Mz MzMzNzRGRkZGRkZGRkZGRkZDQzMzMzNFNjQwMzMzMzMzQ0MNCkZGRkZGRkZGRkZGRkZGNTFBRUZG RkZGRkZGRkZGRkZGRkZGRkRGNUExMTA5MjgwOTVBRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGQkYzMzMzNEM5OTk5RTZGRkZGRkZGRkQ5 MzMzMzRDQ0MzMzMzNUENCkZGRkZGRkZGRkZDQzMzMzM0Q0IzMzMzMzgwRkZGRkZGRkZGRkZGNUEz MzMzQ0MzMzMzNENGRkZGRkZGRkZGRkYNCkNDMzMzMzY2RkYzMzMzNDBGRkZGRkZGRkZGRkZBNTMz MzM2Njk5OTlFNkZGRkZGRkZGRkZGRjRDMzMzMzk5OTkNCkIzRkZGRkZGRkZGRkZGQjMzMzMzODA4 QzMzMzM3NEZGRkZGRkZGRkZGRkZGRkZGRkZGRkZCRjMzMzNBNTMzMzMNCjMzQjMzMzMzOTlGRkZG RkZGRkZGRTYzMzMzMzMzMzMzMzMzM0NDRkZGRkZGRkZGRkZGNUEzMzMzRjI2NjMzMzMNCkZGRkZG RkZGRkZGRkZGRkY4MDMzMzNCRkZGRkZGRkZGRkZGRkZGQ0MzMzMzNzRGRkZGRkZGRkZGRkZDQzMz MzMNCkU2NDAzMzMzMzNDQ0ZGRkZGRkZGRkZGRkZGNzRCRUZGRkZGRkZGRkZGRkZGRkZGRkU1N0I0 MTNBNTMzQTdCRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGQkYzMzMzNEM5OTk5RTZGRkZGRkZGRkQ5MzMNCjMzNENDQzMzMzM1QUZGRkZG RkZGRkZDQzMzMzM0Q0IzMzMzMzgwRkZGRkZGRkZGRkZGNUEzMzMzQ0MzMzMzNEMNCkZGRkZGRkZG RkZGRkNDMzMzMzY2RkYzMzMzNDBGRkZGRkZGRkZGRkZBNTMzMzM2Njk5OTlFNkZGRkZGRkZGRkYN CkZGNEMzMzMzOTk5OUIzRkZGRkZGRkZGRkZGQjMzMzMzODA4QzMzMzM3NEZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkJGMzMzM0E1MzMzMzMzQjMzMzMzOTlGRkZGRkZGRkZGRTYzMzMzMzMzMzMzMzMz M0NDRkZGRkZGRkZGRkZGNUENCjMzMzNGMjY2MzMzM0ZGRkZGRkZGRkZGRkZGRkY4MDMzMzNCRkZG RkZGRkZGRkZGRkZGQ0MzMzMzNzRGRkZGRkYNCkZGRkZGRkNDMzMzM0U2NDAzMzMzMzNDQ0ZGRkZG RkZGRkZGRkZGQjVERkZGRkZGRkZGRkZGRkZGRkZGRkYyQkENCjlDOEVBNDk0QkFGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGQkYzMzMzNEM5 OTk5RTYNCkZGRkZGRkZGRDkzMzMzNENDQzMzMzM1QUZGRkZGRkZGRkZDQzMzMzM0Q0IzMzMzMzgw RkZGRkZGRkZGRkZGNUENCjMzMzNDQzMzMzM0Q0ZGRkZGRkZGRkZGRkNDMzMzMzY2RkYzMzMzNDBG RkZGRkZGRkZGRkZBNTMzMzM2Njk5OTkNCkU2RkZGRkZGRkZGRkZGNEMzMzMzOTk5OUIzRkZGRkZG RkZGRkZGQjMzMzMzODA4QzMzMzM3NEZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkJGMzMzM0E1MzMz MzMzQjMzMzMzOTlGRkZGRkZGRkZGRTYzMzMzMzMzMzMzMzMzM0NDRkYNCkZGRkZGRkZGRkY1QTMz MzNGMjY2MzMzM0ZGRkZGRkZGRkZGRkZGRkY4MDMzMzNCRkZGRkZGRkZGRkZGRkZGQ0MNCjMzMzM3 NEZGRkZGRkZGRkZGRkNDMzMzM0U2NDAzMzMzMzNDQ0ZGRkZGRkZGRkZGRkZGNzBCQ0ZGRkZGRkZG RkYNCkZGRkZGRkZGRTU3ODNDMzU0RjM1NzhGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGOTkNCjMzMzMzMzMzMzNFNkZGRkZGRkZGRkY2NjMz MzMzMzMzNENEOUZGRkZGRkZGRkZGRjVBMzMzMzMzMzM1QUYyRkYNCkZGRkZGRkZGRjIzMzMzNUFG RjRDMzMzM0NDRkZGRkZGRkZGRkE1MzMzMzk5Q0MzMzMzNjZGRkZGRkZGRkZGRkYNCjgwMzMzMzMz MzMzM0U2RkZGRkZGRkZGRkU2MzMzMzMzMzMzMzc0RkZGRkZGRkZGRkZGOEMzMzMzMzMzMzMzNzQN CkYyRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjk5MzMzM0NDMzMzMzRDRDkzMzMzQkZGRkZGRkZGRkZG ODAzMzMzQkYNCkNDNjYzMzMzQkZGRkZGRkZGRkZGRkYzMzMzNENGRjQwMzMzM0ZGRkZGRkZGRkZG RkZGRkY1QTMzMzNFNkZGRkYNCkZGRkZGRkZGRkY5OTMzMzM5OUZGRkZGRkZGRkZGRjk5MzM0MEZG NjYzMzMzMzNGMkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZERjZCMTEwOTE3OEU4 NDAwOUFGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkY5OTMzMzMzMzMzMzNFNkZGRkZGRkZGRkY2NjMzMzMzMzMzNENEOUZGRkZGRkZGRkZG RjVBMzMNCjMzMzMzMzVBRjJGRkZGRkZGRkZGRjIzMzMzNUFGRjRDMzMzM0NDRkZGRkZGRkZGRkE1 MzMzMzk5Q0MzMzMzNjYNCkZGRkZGRkZGRkZGRjgwMzMzMzMzMzMzM0U2RkZGRkZGRkZGRkU2MzMz MzMzMzMzMzc0RkZGRkZGRkZGRkZGOEMNCjMzMzMzMzMzMzM3NEYyRkZGRkZGRkZGRkZGRkZGRkZG RkZGRjk5MzMzM0NDMzMzMzRDRDkzMzMzQkZGRkZGRkYNCkZGRkY4MDMzMzNCRkNDNjYzMzMzQkZG RkZGRkZGRkZGRkYzMzMzNENGRjQwMzMzM0ZGRkZGRkZGRkZGRkZGRkYNCjVBMzMzM0U2RkZGRkZG RkZGRkZGRkY5OTMzMzM5OUZGRkZGRkZGRkZGRjk5MzM0MEZGNjYzMzMzMzNGMkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZFNTg5NDEzQTQ1QTU5RDMzQUVGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkY5OTMzMzMzMzMzMzNF NkZGRkZGRkZGRkY2NjMzMzMzMzMzNENEOUZGRkYNCkZGRkZGRkZGNUEzMzMzMzMzMzVBRjJGRkZG RkZGRkZGRjIzMzMzNUFGRjRDMzMzM0NDRkZGRkZGRkZGRkE1MzMNCjMzOTlDQzMzMzM2NkZGRkZG RkZGRkZGRjgwMzMzMzMzMzMzM0U2RkZGRkZGRkZGRkU2MzMzMzMzMzMzMzc0RkYNCkZGRkZGRkZG RkY4QzMzMzMzMzMzMzM3NEYyRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjk5MzMzM0NDMzMzMzRDRDkN CjMzMzNCRkZGRkZGRkZGRkY4MDMzMzNCRkNDNjYzMzMzQkZGRkZGRkZGRkZGRkYzMzMzNENGRjQw MzMzM0ZGRkYNCkZGRkZGRkZGRkZGRjVBMzMzM0U2RkZGRkZGRkZGRkZGRkY5OTMzMzM5OUZGRkZG RkZGRkZGRjk5MzM0MEZGNjYNCjMzMzMzM0YyRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGMkM0OUM5NDlFRDJDRThERDdGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkY5OTMzMzMzMzMzMzNFNkZGRkZGRkZGRkY2NjMzMzMNCjMz MzM0Q0Q5RkZGRkZGRkZGRkZGNUEzMzMzMzMzMzVBRjJGRkZGRkZGRkZGRjIzMzMzNUFGRjRDMzMz M0NDRkYNCkZGRkZGRkZGQTUzMzMzOTlDQzMzMzM2NkZGRkZGRkZGRkZGRjgwMzMzMzMzMzMzM0U2 RkZGRkZGRkZGRkU2MzMNCjMzMzMzMzMzNzRGRkZGRkZGRkZGRkY4QzMzMzMzMzMzMzM3NEYyRkZG RkZGRkZGRkZGRkZGRkZGRkZGRjk5MzMNCjMzQ0MzMzMzNENEOTMzMzNCRkZGRkZGRkZGRkY4MDMz MzNCRkNDNjYzMzMzQkZGRkZGRkZGRkZGRkYzMzMzNEMNCkZGNDAzMzMzRkZGRkZGRkZGRkZGRkZG RjVBMzMzM0U2RkZGRkZGRkZGRkZGRkY5OTMzMzM5OUZGRkZGRkZGRkYNCkZGOTkzMzQwRkY2NjMz MzMzM0YyRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZFNTg2M0MzNTQxQTINCjlCMkVB REZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZCMzk5OTk5OTk5OTlGRkZGRkYNCkZGRkZGRkZGQTU4Qzk5QjNGRkZGRkZGRkZGRkZGRkZGRjJB NThDOTlCM0ZGRkZGRkZGRkZGRkZGRTY5OTk5QjMNCkZGQjM5OTk5Q0NGRkZGRkZGRkZGQkY5OTk5 RDlEOTk5OTlDQ0ZGRkZGRkZGRkZGRkIzOTk5OTk5OTk5OUZGRkYNCkZGRkZGRkZGRTY5OTk5OTk5 OTk5Q0NGRkZGRkZGRkZGRkZCMzk5OTk5OUE1RDlGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG QjM5OUIzRTY5OTk5QkZFNjk5OTlFNkZGRkZGRkZGRjI5OTk5QjNGRkZGQ0M5OTk5Q0NGRkZGRkYN CkZGRkZFNjk5OTlCM0ZGOTk5OTk5RkZGRkZGRkZGRkZGRkZGRjk5OTk5OUZGRkZGRkZGRkZGRkZG RkZCRjk5OTkNCkU2RkZGRkZGRkZGRkZGQkY5OUIzRkZCMzk5OTk5OUZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkUzODQNCjIxMDAwOThFRkZGRjQ2MDlENUZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZCMzk5OTkNCjk5OTk5OUZGRkZG RkZGRkZGRkZGQTU4Qzk5QjNGRkZGRkZGRkZGRkZGRkZGRjJBNThDOTlCM0ZGRkZGRkZGRkYNCkZG RkZFNjk5OTlCM0ZGQjM5OTk5Q0NGRkZGRkZGRkZGQkY5OTk5RDlEOTk5OTlDQ0ZGRkZGRkZGRkZG RkIzOTkNCjk5OTk5OTk5RkZGRkZGRkZGRkZGRTY5OTk5OTk5OTk5Q0NGRkZGRkZGRkZGRkZCMzk5 OTk5OUE1RDlGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGQjM5OUIzRTY5OTk5QkZFNjk5OTlF NkZGRkZGRkZGRjI5OTk5QjNGRkZGQ0MNCjk5OTlDQ0ZGRkZGRkZGRkZFNjk5OTlCM0ZGOTk5OTk5 RkZGRkZGRkZGRkZGRkZGRjk5OTk5OUZGRkZGRkZGRkYNCkZGRkZGRkJGOTk5OUU2RkZGRkZGRkZG RkZGQkY5OUIzRkZCMzk5OTk5OUZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRTk5RDRE MzMzQUE1RkZGRjZCM0FEREZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkIzOTk5OTk5OTk5OUZGRkZGRkZGRkZGRkZGQTU4Qzk5QjNGRkZG RkZGRkZGRkZGRkZGRjJBNThDOTkNCkIzRkZGRkZGRkZGRkZGRkZFNjk5OTlCM0ZGQjM5OTk5Q0NG RkZGRkZGRkZGQkY5OTk5RDlEOTk5OTlDQ0ZGRkYNCkZGRkZGRkZGQjM5OTk5OTk5OTk5RkZGRkZG RkZGRkZGRTY5OTk5OTk5OTk5Q0NGRkZGRkZGRkZGRkZCMzk5OTkNCjk5QTVEOUZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGQjM5OUIzRTY5OTk5QkZFNjk5OTlFNkZGRkZGRkZGRjINCjk5OTlCM0ZG RkZDQzk5OTlDQ0ZGRkZGRkZGRkZFNjk5OTlCM0ZGOTk5OTk5RkZGRkZGRkZGRkZGRkZGRjk5OTkN Cjk5RkZGRkZGRkZGRkZGRkZGRkJGOTk5OUU2RkZGRkZGRkZGRkZGQkY5OUIzRkZCMzk5OTk5OUZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRjRDRTlGOTk5Q0QyRkZGRkIzOTRFRUZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkIz OTk5OTk5OTk5OUZGRkZGRkZGRkZGRkZGQTU4Qzk5QjNGRkZGRkZGRkZGRkYNCkZGRkZGMkE1OEM5 OUIzRkZGRkZGRkZGRkZGRkZFNjk5OTlCM0ZGQjM5OTk5Q0NGRkZGRkZGRkZGQkY5OTk5RDkNCkQ5 OTk5OUNDRkZGRkZGRkZGRkZGQjM5OTk5OTk5OTk5RkZGRkZGRkZGRkZGRTY5OTk5OTk5OTk5Q0NG RkZGRkYNCkZGRkZGRkIzOTk5OTk5QTVEOUZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGQjM5OUIz RTY5OTk5QkZFNjk5OTkNCkU2RkZGRkZGRkZGMjk5OTlCM0ZGRkZDQzk5OTlDQ0ZGRkZGRkZGRkZF Njk5OTlCM0ZGOTk5OTk5RkZGRkZGRkYNCkZGRkZGRkZGOTk5OTk5RkZGRkZGRkZGRkZGRkZGRkJG OTk5OUU2RkZGRkZGRkZGRkZGQkY5OUIzRkZCMzk5OTkNCjk5RkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRTg5QjQ4MkYzNkEyRkZGRjY4MzVEREZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGMzlFMjgwOTIxOENGM0ZG RkZGRjE3MjgNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGNUIxNTMzQTREQTMNCkY1RkZGRkZGNDU1M0ZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZBRDZBNDk0OUZDRkZBRkZGRkZGOUVBNEZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkY1QjA0RjM1NDhBMUY1RkZGRkZG NDE0RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZBNTIwMDkyMThDRTdGRkZGRkZGRkRGMDk3MkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZCNzREM0E0 REEzRUNGRkZGRkZGRkU1M0E4RUZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZEQkEzOTQ5RkNGRjVGRkZGRkYNCkZGRjI5Q0M1 RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZCNjQ4MzUNCjQ4QTFFQkZGRkZGRkZGRTUzNjhDRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGQjQzMDA5MTc4Q0YxRkZG RkZGRkZGRkZGQUUwMEFFRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGQzM1OTNBNDVBM0Y0RkZGRkZGRkZGRkZGQkUzM0JFRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RTFBNzlDOUVDRkY5RkZGRkZGRkZGRkZGREY5OURGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGQzI1NTM2NDFBMUYzRkZGRkZGRkZG RkZGQkMNCjJGQkNGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZDMTQ2MTEwOTdDRjNGRkZGRkYNCkZGRkZGRkZGRkY2NzAwRjFGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZDRDZCNDENCjNB OTZGNUZGRkZGRkZGRkZGRkZGRkY4NTMzRjRGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkU2QjM5QzlDQ0JGQUZGRkZGRkZGRkZGRkZGRkZD MTk5RjlGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkNDNjgzQzM2OTRGNUZGRkZGRkZGRkZGRkZGRkY4MjJGRjNGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRTM1QTExMTE3MkY3RkZGRkZG RkZGRkZGRkZGRkZGRkYzMDMwRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRTk3QjQxNDE4RUY5RkZGRkZGRkZGRkZGRkYNCkZGRkZGRjU5NTlG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjRC QTlDOUNDNUZDRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkE3QTdGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRTgNCjc4M0MzQzhDRjlGRkZGRkZGRkZG RkZGRkZGRkZGRjU1NTVGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkYzNUEwMDE3ODRFN0ZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGNzA5ODRGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkY1N0IzMzQ1OURF Q0ZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGOTNBOURGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZBQkE5OTlFQ0VGNUZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZDOUNDRUZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkY1NzgyRjQxOUJFQkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkY5MzY5QkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRjM3QzA5MTE4NEU3RkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkMxMDBDMUZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRjUNCjk2M0E0MTlERUNGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkNE MzNDREZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGQUNC OUM5Q0NFRjVGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkU2OTlFNkZGRkZGRkZGRkYNCkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYN CkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGNTk0MzYzQzlCRUJGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkNDMkYNCkNDRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZGRkZGRkZGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkYNCkZG RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZGRkYNCkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZG RkZG