Re: [U2] OPENSEQ
I've never used OPENSEQ on a remote drive like that. I presume you can LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the OPENSEQ should work with that just fine. May I also presume that you looed at FNAME and a file with that name really does exist in that directory file? On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt adew...@stylmark.com wrote: Please educate me on OPENSEQ. I have some code that is giving me an error. The funny thing is that I stole the code from a working program: The code: 064: FNAME = 'LLV':FNAME:'.XLS' 065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO OUT.FILE ELSE 066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE 067: ERRCD = STATUS() 068: GOSUB 900 069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is aborting.') 070: GO 071: END If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66 ERRCD = 0. According to manual 2 means: The file does not exist. A 0 means The record does not exist. In my voc file I have an entry for LRGLBRVARS. It looks like this: Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\led\fs-styl\Public\LrgLbrVariances 003: D_HOLD_ Bottom. What is OPENSEQ looking for and where does it expect it to find it? Thanks. Albert DeWitt, CPIM ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ
I'm pretty sure Universe can open windows SMB drives, but I don't know that I ever tried it with other MV systems. Keep in mind the most important thing about windows SMB drive shares: unless you are logged into the desktop, it doesn't automatically map them. You may need to issue a net use command to authenticate the share (or set it up within windows so that authentication is not needed.) *Aaron Titus* Senior Software Engineer F.W. Davison Company, Inc. 508-747-7261 x245 ati...@fwdco.com On Mon, Aug 5, 2013 at 9:31 AM, Kevin King ke...@precisonline.com wrote: I've never used OPENSEQ on a remote drive like that. I presume you can LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the OPENSEQ should work with that just fine. May I also presume that you looed at FNAME and a file with that name really does exist in that directory file? On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt adew...@stylmark.com wrote: Please educate me on OPENSEQ. I have some code that is giving me an error. The funny thing is that I stole the code from a working program: The code: 064: FNAME = 'LLV':FNAME:'.XLS' 065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO OUT.FILE ELSE 066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE 067: ERRCD = STATUS() 068: GOSUB 900 069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is aborting.') 070: GO 071: END If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66 ERRCD = 0. According to manual 2 means: The file does not exist. A 0 means The record does not exist. In my voc file I have an entry for LRGLBRVARS. It looks like this: Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\led\fs-styl\Public\LrgLbrVariances 003: D_HOLD_ Bottom. What is OPENSEQ looking for and where does it expect it to find it? Thanks. Albert DeWitt, CPIM ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ
If you have LRGLBRVARS as a VOC pointer and can LIST LRGLBRVARS then OPENSEQ 'LRGLBRVARS',FNAME TO OUT.FILE ELSE NULL should do it if you know it is present (if the XLS is open with Excel you will usually get an abort) Although I personally would check it is actually there via normal read syntax first OPEN 'LRGLBRVARS' TO LRGLBRVARS ELSE STOP 201,'LRGLBRVARS' READ CHECKITSTHERE FROM LRGLBRVARS,FNAME ELSE STOP 201,FNAME - Epicor Software (UK) is a limited company registered in England Wales. Registration Number: 2338274. Registered Office: 6th Floor, One London Wall, London EC2Y 5EB This e-mail and any attachments to it are confidential and is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. Any views and/or opinions expressed in this e-mail are of the author only and do not represent the views of Epicor Software (UK) Limited or any other company within its group. - -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: 05 August 2013 14:31 To: U2 Users List Subject: Re: [U2] OPENSEQ I've never used OPENSEQ on a remote drive like that. I presume you can LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the OPENSEQ should work with that just fine. May I also presume that you looked at FNAME and a file with that name really does exist in that directory file? On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt adew...@stylmark.com wrote: Please educate me on OPENSEQ. I have some code that is giving me an error. The funny thing is that I stole the code from a working program: The code: 064: FNAME = 'LLV':FNAME:'.XLS' 065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO OUT.FILE ELSE 066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE 067: ERRCD = STATUS() 068: GOSUB 900 069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is aborting.') 070: GO 071: END If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66 ERRCD = 0. According to manual 2 means: The file does not exist. A 0 means The record does not exist. In my voc file I have an entry for LRGLBRVARS. It looks like this: Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\led\fs-styl\Public\LrgLbrVariances 003: D_HOLD_ Bottom. What is OPENSEQ looking for and where does it expect it to find it? Thanks. Albert DeWitt, CPIM This message has been scanned for malware by Websense. www.websense.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ
Spot the spilling miss steak. and that will of course be 202,FNAME - Epicor Software (UK) is a limited company registered in England Wales. Registration Number: 2338274. Registered Office: 6th Floor, One London Wall, London EC2Y 5EB This e-mail and any attachments to it are confidential and is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. Any views and/or opinions expressed in this e-mail are of the author only and do not represent the views of Epicor Software (UK) Limited or any other company within its group. - -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin Braid Sent: 05 August 2013 14:48 To: U2 Users List Subject: Re: [U2] OPENSEQ If you have LRGLBRVARS as a VOC pointer and can LIST LRGLBRVARS then OPENSEQ 'LRGLBRVARS',FNAME TO OUT.FILE ELSE NULL should do it if you know it is present (if the XLS is open with Excel you will usually get an abort) Although I personally would check it is actually there via normal read syntax first OPEN 'LRGLBRVARS' TO LRGLBRVARS ELSE STOP 201,'LRGLBRVARS' READ CHECKITSTHERE FROM LRGLBRVARS,FNAME ELSE STOP 201,FNAME - Epicor Software (UK) is a limited company registered in England Wales. Registration Number: 2338274. Registered Office: 6th Floor, One London Wall, London EC2Y 5EB This e-mail and any attachments to it are confidential and is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. Any views and/or opinions expressed in this e-mail are of the author only and do not represent the views of Epicor Software (UK) Limited or any other company within its group. - -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: 05 August 2013 14:31 To: U2 Users List Subject: Re: [U2] OPENSEQ I've never used OPENSEQ on a remote drive like that. I presume you can LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the OPENSEQ should work with that just fine. May I also presume that you looked at FNAME and a file with that name really does exist in that directory file? On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt adew...@stylmark.com wrote: Please educate me on OPENSEQ. I have some code that is giving me an error. The funny thing is that I stole the code from a working program: The code: 064: FNAME = 'LLV':FNAME:'.XLS' 065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO OUT.FILE ELSE 066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE 067: ERRCD = STATUS() 068: GOSUB 900 069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is aborting.') 070: GO 071: END If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66 ERRCD = 0. According to manual 2 means: The file does not exist. A 0 means The record does not exist. In my voc file I have an entry for LRGLBRVARS. It looks like this: Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\led\fs-styl\Public\LrgLbrVariances 003: D_HOLD_ Bottom. What is OPENSEQ looking for and where does it expect it to find it? Thanks. Albert DeWitt, CPIM This message has been scanned for malware by Websense. www.websense.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users Click https://www.mailcontrol.com/sr/xTPlpmVs7T!GX2PQPOmvUnx5AcfplCJVvID731zL8nSDZHbh!LQJTNwGoUldJppTIyW01XaW!eLX405xsHCs!A== to report this email as spam. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ
I could be wrong, but I seem to recall that OPENSEQ supports two syntaxes Option 1 has 2 arguments: openseq voc.pointer, filename to ... Option 2 has only 1 argument: openseq absolute.path.to.filename to ... Also, if the server where your shared folder resides is not Windows, then filenames will be case sensitive. Larry Hiscock Western Computer Services -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Al DeWitt Sent: Monday, August 05, 2013 6:10 AM To: (u2-users@listserver.u2ug.org) Subject: [U2] OPENSEQ Please educate me on OPENSEQ. I have some code that is giving me an error. The funny thing is that I stole the code from a working program: The code: 064: FNAME = 'LLV':FNAME:'.XLS' 065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO OUT.FILE ELSE 066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE 067: ERRCD = STATUS() 068: GOSUB 900 069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is aborting.') 070: GO 071: END If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66 ERRCD = 0. According to manual 2 means: The file does not exist. A 0 means The record does not exist. In my voc file I have an entry for LRGLBRVARS. It looks like this: Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\led\fs-styl\Public\LrgLbrVariances 003: D_HOLD_ Bottom. What is OPENSEQ looking for and where does it expect it to find it? Thanks. Albert DeWitt, CPIM ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ
Thanks for your reply Kevin. I can list LRGLBRVARS at TCL. I put a dummy file inside to prove it. FNAME does not exist. In the code I stole this from the name is created anew each time. It always open the file empty, allows me to populate and close it. However, in this code it's not working. Since we're running SB+/SBClient I thought the '.XLS' extension was causing issues (grasping at straws) but I'm getting the same errors. Albert DeWitt, CPIM Sr. Programmer Analyst Stylmark, Inc. 6536 Main St NE | Minneapolis MN 55432 | USA DD: 763-574-8705 | PH: 763-574-7474 | F: 763-574-1415 adew...@stylmark.com www.stylmark.com Stylmark is a proud member of RDI, ARE, NGA You can now find Stylmark on LinkedIn and Facebook -Original Message- From: Kevin King [mailto:ke...@precisonline.com] Sent: Monday, August 05, 2013 8:31 AM To: U2 Users List Subject: Re: [U2] OPENSEQ I've never used OPENSEQ on a remote drive like that. I presume you can LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the OPENSEQ should work with that just fine. May I also presume that you looed at FNAME and a file with that name really does exist in that directory file? On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt adew...@stylmark.com wrote: Please educate me on OPENSEQ. I have some code that is giving me an error. The funny thing is that I stole the code from a working program: The code: 064: FNAME = 'LLV':FNAME:'.XLS' 065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO OUT.FILE ELSE 066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE 067: ERRCD = STATUS() 068: GOSUB 900 069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is aborting.') 070: GO 071: END If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66 ERRCD = 0. According to manual 2 means: The file does not exist. A 0 means The record does not exist. In my voc file I have an entry for LRGLBRVARS. It looks like this: Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\led\fs-styl\Public\LrgLbrVariances 003: D_HOLD_ Bottom. What is OPENSEQ looking for and where does it expect it to find it? Thanks. Albert DeWitt, CPIM ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ
Does the code still fail with the dummy file out there? If not, I'd guess permissions. From: Al DeWitt adew...@stylmark.com To: U2 Users List u2-users@listserver.u2ug.org, Date: 08/05/2013 09:04 AM Subject:Re: [U2] OPENSEQ Sent by:u2-users-boun...@listserver.u2ug.org Thanks for your reply Kevin. I can list LRGLBRVARS at TCL. I put a dummy file inside to prove it. FNAME does not exist. In the code I stole this from the name is created anew each time. It always open the file empty, allows me to populate and close it. However, in this code it's not working. Since we're running SB+/SBClient I thought the '.XLS' extension was causing issues (grasping at straws) but I'm getting the same errors. Albert DeWitt, CPIM Sr. Programmer Analyst Stylmark, Inc. 6536 Main St NE | Minneapolis MN 55432 | USA DD: 763-574-8705 | PH: 763-574-7474 | F: 763-574-1415 adew...@stylmark.com www.stylmark.com Stylmark is a proud member of RDI, ARE, NGA You can now find Stylmark on LinkedIn and Facebook -Original Message- From: Kevin King [mailto:ke...@precisonline.com] Sent: Monday, August 05, 2013 8:31 AM To: U2 Users List Subject: Re: [U2] OPENSEQ I've never used OPENSEQ on a remote drive like that. I presume you can LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the OPENSEQ should work with that just fine. May I also presume that you looed at FNAME and a file with that name really does exist in that directory file? On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt adew...@stylmark.com wrote: Please educate me on OPENSEQ. I have some code that is giving me an error. The funny thing is that I stole the code from a working program: The code: 064: FNAME = 'LLV':FNAME:'.XLS' 065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO OUT.FILE ELSE 066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE 067: ERRCD = STATUS() 068: GOSUB 900 069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is aborting.') 070: GO 071: END If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66 ERRCD = 0. According to manual 2 means: The file does not exist. A 0 means The record does not exist. In my voc file I have an entry for LRGLBRVARS. It looks like this: Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\led\fs-styl\Public\LrgLbrVariances 003: D_HOLD_ Bottom. What is OPENSEQ looking for and where does it expect it to find it? Thanks. Albert DeWitt, CPIM ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users U.S. BANCORP made the following annotations - Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. - ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ
I'm a Domain Admin so permissions is not an issue. I'm going back to the beginning and start over. Maybe I have an issue I'm not seeing. Thanks for all your help. Albert DeWitt, CPIM Sr. Programmer Analyst Stylmark, Inc. 6536 Main St NE | Minneapolis MN 55432 | USA DD: 763-574-8705 | PH: 763-574-7474 | F: 763-574-1415 adew...@stylmark.com www.stylmark.com Stylmark is a proud member of RDI, ARE, NGA You can now find Stylmark on LinkedIn and Facebook -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of bradley.sch...@usbank.com Sent: Monday, August 05, 2013 9:10 AM To: U2 Users List Subject: Re: [U2] OPENSEQ Does the code still fail with the dummy file out there? If not, I'd guess permissions. From: Al DeWitt adew...@stylmark.com To: U2 Users List u2-users@listserver.u2ug.org, Date: 08/05/2013 09:04 AM Subject:Re: [U2] OPENSEQ Sent by:u2-users-boun...@listserver.u2ug.org Thanks for your reply Kevin. I can list LRGLBRVARS at TCL. I put a dummy file inside to prove it. FNAME does not exist. In the code I stole this from the name is created anew each time. It always open the file empty, allows me to populate and close it. However, in this code it's not working. Since we're running SB+/SBClient I thought the '.XLS' extension was causing issues (grasping at straws) but I'm getting the same errors. Albert DeWitt, CPIM Sr. Programmer Analyst Stylmark, Inc. 6536 Main St NE | Minneapolis MN 55432 | USA DD: 763-574-8705 | PH: 763-574-7474 | F: 763-574-1415 adew...@stylmark.com www.stylmark.com Stylmark is a proud member of RDI, ARE, NGA You can now find Stylmark on LinkedIn and Facebook -Original Message- From: Kevin King [mailto:ke...@precisonline.com] Sent: Monday, August 05, 2013 8:31 AM To: U2 Users List Subject: Re: [U2] OPENSEQ I've never used OPENSEQ on a remote drive like that. I presume you can LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the OPENSEQ should work with that just fine. May I also presume that you looed at FNAME and a file with that name really does exist in that directory file? On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt adew...@stylmark.com wrote: Please educate me on OPENSEQ. I have some code that is giving me an error. The funny thing is that I stole the code from a working program: The code: 064: FNAME = 'LLV':FNAME:'.XLS' 065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO OUT.FILE ELSE 066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE 067: ERRCD = STATUS() 068: GOSUB 900 069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is aborting.') 070: GO 071: END If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66 ERRCD = 0. According to manual 2 means: The file does not exist. A 0 means The record does not exist. In my voc file I have an entry for LRGLBRVARS. It looks like this: Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\led\fs-styl\Public\LrgLbrVariances 003: D_HOLD_ Bottom. What is OPENSEQ looking for and where does it expect it to find it? Thanks. Albert DeWitt, CPIM ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users U.S. BANCORP made the following annotations - Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. - ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ
...Aaaah. If it is NOT there then do this:- OPEN 'LRGLBRVARS' TO LRGLBRVARS ELSE STOP 201,'LRGLBRVARS' WRITE ON LRGLBRVARS,FNAME OPENSEQ 'LRGLBRVARS',FNAME TO OUT.FILE ELSE NULL - Epicor Software (UK) is a limited company registered in England Wales. Registration Number: 2338274. Registered Office: 6th Floor, One London Wall, London EC2Y 5EB This e-mail and any attachments to it are confidential and is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. Any views and/or opinions expressed in this e-mail are of the author only and do not represent the views of Epicor Software (UK) Limited or any other company within its group. - -Original Message- From: Martin Braid Sent: 05 August 2013 14:52 To: U2 Users List Subject: RE: [U2] OPENSEQ Spot the spilling miss steak. and that will of course be 202,FNAME -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin Braid Sent: 05 August 2013 14:48 To: U2 Users List Subject: Re: [U2] OPENSEQ If you have LRGLBRVARS as a VOC pointer and can LIST LRGLBRVARS then OPENSEQ 'LRGLBRVARS',FNAME TO OUT.FILE ELSE NULL should do it if you know it is present (if the XLS is open with Excel you will usually get an abort) Although I personally would check it is actually there via normal read syntax first OPEN 'LRGLBRVARS' TO LRGLBRVARS ELSE STOP 201,'LRGLBRVARS' READ CHECKITSTHERE FROM LRGLBRVARS,FNAME ELSE STOP 201,FNAME - Epicor Software (UK) is a limited company registered in England Wales. Registration Number: 2338274. Registered Office: 6th Floor, One London Wall, London EC2Y 5EB This e-mail and any attachments to it are confidential and is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. Any views and/or opinions expressed in this e-mail are of the author only and do not represent the views of Epicor Software (UK) Limited or any other company within its group. - -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kevin King Sent: 05 August 2013 14:31 To: U2 Users List Subject: Re: [U2] OPENSEQ I've never used OPENSEQ on a remote drive like that. I presume you can LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the OPENSEQ should work with that just fine. May I also presume that you looked at FNAME and a file with that name really does exist in that directory file? On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt adew...@stylmark.com wrote: Please educate me on OPENSEQ. I have some code that is giving me an error. The funny thing is that I stole the code from a working program: The code: 064: FNAME = 'LLV':FNAME:'.XLS' 065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO OUT.FILE ELSE 066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE 067: ERRCD = STATUS() 068: GOSUB 900 069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is aborting.') 070: GO 071: END If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66 ERRCD = 0. According to manual 2 means: The file does not exist. A 0 means The record does not exist. In my voc file I have an entry for LRGLBRVARS. It looks like this: Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\led\fs-styl\Public\LrgLbrVariances 003: D_HOLD_ Bottom. What is OPENSEQ looking for and where does it expect it to find it? Thanks. Albert DeWitt, CPIM This message has been scanned for malware by Websense. www.websense.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users Click https://www.mailcontrol.com/sr/xTPlpmVs7T!GX2PQPOmvUnx5AcfplCJVvID731zL8nSDZHbh!LQJTNwGoUldJppTIyW01XaW!eLX405xsHCs!A== to report this email as spam
Re: [U2] OPENSEQ
Can someone point me to the page where we can use DIR type files at all? It would make my job a lot easier! -Original Message- From: Al DeWitt adew...@stylmark.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, Aug 5, 2013 7:04 am Subject: Re: [U2] OPENSEQ Thanks for your reply Kevin. I can list LRGLBRVARS at TCL. I put a dummy file inside to prove it. FNAME does not exist. In the code I stole this from the name is created anew each time. It always open the file empty, allows me to populate and close it. However, in this code it's not working. Since we're running SB+/SBClient I thought the '.XLS' extension was causing issues (grasping at straws) but I'm getting the same errors. Albert DeWitt, CPIM Sr. Programmer Analyst Stylmark, Inc. 6536 Main St NE | Minneapolis MN 55432 | USA DD: 763-574-8705 | PH: 763-574-7474 | F: 763-574-1415 adew...@stylmark.com www.stylmark.com Stylmark is a proud member of RDI, ARE, NGA You can now find Stylmark on LinkedIn and Facebook -Original Message- From: Kevin King [mailto:ke...@precisonline.com] Sent: Monday, August 05, 2013 8:31 AM To: U2 Users List Subject: Re: [U2] OPENSEQ I've never used OPENSEQ on a remote drive like that. I presume you can LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the OPENSEQ should work with that just fine. May I also presume that you looed at FNAME and a file with that name really does exist in that directory file? On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt adew...@stylmark.com wrote: Please educate me on OPENSEQ. I have some code that is giving me an error. The funny thing is that I stole the code from a working program: The code: 064: FNAME = 'LLV':FNAME:'.XLS' 065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO OUT.FILE ELSE 066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE 067: ERRCD = STATUS() 068: GOSUB 900 069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is aborting.') 070: GO 071: END If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66 ERRCD = 0. According to manual 2 means: The file does not exist. A 0 means The record does not exist. In my voc file I have an entry for LRGLBRVARS. It looks like this: Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\led\fs-styl\Public\LrgLbrVariances 003: D_HOLD_ Bottom. What is OPENSEQ looking for and where does it expect it to find it? Thanks. Albert DeWitt, CPIM ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ
Al:
UniData help shows...
Help Information For: UNIBASIC OPENSEQ
Page: 1/5
OPENSEQ
Syntax
OPENSEQ [absolutepath | seq.filename,record.id] [READONLY] TO seq.file.var
[ON ERROR statements] [LOCKED statements] {THEN statements [END]
| ELSE statements [END]}
OPENSEQ [absolutepath | seq.filename,record.id] [READONLY] TO seq.file.var
[LOCKED statements] [ON ERROR statements] {THEN statements [END]
| ELSE statements [END]}
Description
The UniBasic OPENSEQ command opens a sequential file for access,
starting at the specified record. UniData limits to 150 the number
of sequential files you can open in a UniBasic program.
It would seem your path uses the seq.filename, record.id format
instead of the absolute path format. e.g.
065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances\:FNAME TO
OUT.FILE ELSE
HTH (and fixes it).
Bill
Untitled Page
- Original Message -
*From:* adew...@stylmark.com
*To:* U2 Users List u2-users@listserver.u2ug.org
*Date:* 8/5/2013 7:17 AM
*Subject:* Re: [U2] OPENSEQ
I'm a Domain Admin so permissions is not an issue. I'm going back to the
beginning and start over. Maybe I have an issue I'm not seeing.
Thanks for all your help.
Albert DeWitt, CPIM
Sr. Programmer Analyst
Stylmark, Inc.
6536 Main St NE | Minneapolis MN 55432 | USA
DD: 763-574-8705 | PH: 763-574-7474 | F: 763-574-1415
adew...@stylmark.com
www.stylmark.com
Stylmark is a proud member of RDI, ARE, NGA
You can now find Stylmark on LinkedIn and Facebook
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of
bradley.sch...@usbank.com
Sent: Monday, August 05, 2013 9:10 AM
To: U2 Users List
Subject: Re: [U2] OPENSEQ
Does the code still fail with the dummy file out there? If not, I'd guess
permissions.
From: Al DeWitt adew...@stylmark.com
To: U2 Users List u2-users@listserver.u2ug.org,
Date: 08/05/2013 09:04 AM
Subject:Re: [U2] OPENSEQ
Sent by:u2-users-boun...@listserver.u2ug.org
Thanks for your reply Kevin.
I can list LRGLBRVARS at TCL. I put a dummy file inside to prove it.
FNAME does not exist. In the code I stole this from the name is created
anew each time. It always open the file empty, allows me to populate
and close it. However, in this code it's not working.
Since we're running SB+/SBClient I thought the '.XLS' extension was
causing issues (grasping at straws) but I'm getting the same errors.
Albert DeWitt, CPIM
Sr. Programmer Analyst
Stylmark, Inc.
6536 Main St NE | Minneapolis MN 55432 | USA
DD: 763-574-8705 | PH: 763-574-7474 | F: 763-574-1415
adew...@stylmark.com
www.stylmark.com
Stylmark is a proud member of RDI, ARE, NGA
You can now find Stylmark on LinkedIn and Facebook
-Original Message-
From: Kevin King [mailto:ke...@precisonline.com]
Sent: Monday, August 05, 2013 8:31 AM
To: U2 Users List
Subject: Re: [U2] OPENSEQ
I've never used OPENSEQ on a remote drive like that. I presume you can
LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the
OPENSEQ should work with that just fine. May I also presume that you
looed at FNAME and a file with that name really does exist in that
directory file?
On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt adew...@stylmark.com wrote:
Please educate me on OPENSEQ. I have some code that is giving me an
error. The funny thing is that I stole the code from a working program:
The code:
064: FNAME = 'LLV':FNAME:'.XLS'
065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO
OUT.FILE ELSE
066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE
067: ERRCD = STATUS()
068: GOSUB 900
069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is aborting.')
070: GO
071: END
If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66
ERRCD = 0. According to manual 2 means: The file does not exist. A 0
means The record does not exist.
In my voc file I have an entry for LRGLBRVARS. It looks like this:
Top of LRGLBRVARS in VOC, 3 lines, 48 characters.
001: DIR
002: \\led\fs-styl\Public\LrgLbrVariances
003: D_HOLD_
Bottom.
What is OPENSEQ looking for and where does it expect it to find it?
Thanks.
Albert DeWitt, CPIM
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ
*Falls out of my chair*
What ? What ?
I never knew you could DO this!
After some fiddling about I finally was able to make OPENSEQ open an UNC path.
Of course the one I tried, actually points to the exact same server and account
the code is already running in, but I didn't even know you could OPEN an UNC
path at all before! I've been translating the UNC paths into DOS paths.
Now to try to open remote UNC path
-Original Message-
From: Bill Haskett wphask...@advantos.net
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Mon, Aug 5, 2013 10:05 am
Subject: Re: [U2] OPENSEQ
Al:
UniData help shows...
Help Information For: UNIBASIC OPENSEQ
Page: 1/5
OPENSEQ
Syntax
OPENSEQ [absolutepath | seq.filename,record.id] [READONLY] TO seq.file.var
[ON ERROR statements] [LOCKED statements] {THEN statements [END]
| ELSE statements [END]}
OPENSEQ [absolutepath | seq.filename,record.id] [READONLY] TO seq.file.var
[LOCKED statements] [ON ERROR statements] {THEN statements [END]
| ELSE statements [END]}
Description
The UniBasic OPENSEQ command opens a sequential file for access,
starting at the specified record. UniData limits to 150 the number
of sequential files you can open in a UniBasic program.
It would seem your path uses the seq.filename, record.id format
instead of the absolute path format. e.g.
065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances\:FNAME TO
OUT.FILE ELSE
HTH (and fixes it).
Bill
Untitled Page
- Original Message -
*From:* adew...@stylmark.com
*To:* U2 Users List u2-users@listserver.u2ug.org
*Date:* 8/5/2013 7:17 AM
*Subject:* Re: [U2] OPENSEQ
I'm a Domain Admin so permissions is not an issue. I'm going back to the
beginning and start over. Maybe I have an issue I'm not seeing.
Thanks for all your help.
Albert DeWitt, CPIM
Sr. Programmer Analyst
Stylmark, Inc.
6536 Main St NE | Minneapolis MN 55432 | USA
DD: 763-574-8705 | PH: 763-574-7474 | F: 763-574-1415
adew...@stylmark.com
www.stylmark.com
Stylmark is a proud member of RDI, ARE, NGA
You can now find Stylmark on LinkedIn and Facebook
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org]
On Behalf Of bradley.sch...@usbank.com
Sent: Monday, August 05, 2013 9:10 AM
To: U2 Users List
Subject: Re: [U2] OPENSEQ
Does the code still fail with the dummy file out there? If not, I'd guess
permissions.
From: Al DeWitt adew...@stylmark.com
To: U2 Users List u2-users@listserver.u2ug.org,
Date: 08/05/2013 09:04 AM
Subject:Re: [U2] OPENSEQ
Sent by:u2-users-boun...@listserver.u2ug.org
Thanks for your reply Kevin.
I can list LRGLBRVARS at TCL. I put a dummy file inside to prove it.
FNAME does not exist. In the code I stole this from the name is created
anew each time. It always open the file empty, allows me to populate
and close it. However, in this code it's not working.
Since we're running SB+/SBClient I thought the '.XLS' extension was
causing issues (grasping at straws) but I'm getting the same errors.
Albert DeWitt, CPIM
Sr. Programmer Analyst
Stylmark, Inc.
6536 Main St NE | Minneapolis MN 55432 | USA
DD: 763-574-8705 | PH: 763-574-7474 | F: 763-574-1415
adew...@stylmark.com
www.stylmark.com
Stylmark is a proud member of RDI, ARE, NGA
You can now find Stylmark on LinkedIn and Facebook
-Original Message-
From: Kevin King [mailto:ke...@precisonline.com]
Sent: Monday, August 05, 2013 8:31 AM
To: U2 Users List
Subject: Re: [U2] OPENSEQ
I've never used OPENSEQ on a remote drive like that. I presume you can
LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the
OPENSEQ should work with that just fine. May I also presume that you
looed at FNAME and a file with that name really does exist in that
directory file?
On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt adew...@stylmark.com wrote:
Please educate me on OPENSEQ. I have some code that is giving me an
error. The funny thing is that I stole the code from a working program:
The code:
064: FNAME = 'LLV':FNAME:'.XLS'
065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO
OUT.FILE ELSE
066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE
067: ERRCD = STATUS()
068: GOSUB 900
069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is
aborting.')
070: GO
071: END
If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66
ERRCD = 0. According to manual 2 means: The file does not exist. A 0
means The record does not exist.
In my voc file I have an entry for LRGLBRVARS. It looks like this:
Top
Re: [U2] OPENSEQ
Remember, if you're using Windows 2008 (Vista Server) or later (I use
2008 R2 - Windows 7 Server) then you have to be careful about how you
share the network directory you want to share.
For testing purposes, if you're using Windows, it may be a good idea to
share the directory to everyone, with full permissions.
Bill
Untitled Page
- Original Message -
*From:* wjhon...@aol.com
*To:* u2-users@listserver.u2ug.org
*Date:* 8/5/2013 10:16 AM
*Subject:* Re: [U2] OPENSEQ
*Falls out of my chair*
What ? What ?
I never knew you could DO this!
After some fiddling about I finally was able to make OPENSEQ open an UNC path.
Of course the one I tried, actually points to the exact same server and account
the code is already running in, but I didn't even know you could OPEN an UNC
path at all before! I've been translating the UNC paths into DOS paths.
Now to try to open remote UNC path
-Original Message-
From: Bill Haskett wphask...@advantos.net
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Mon, Aug 5, 2013 10:05 am
Subject: Re: [U2] OPENSEQ
Al:
UniData help shows...
Help Information For: UNIBASIC OPENSEQ
Page: 1/5
OPENSEQ
Syntax
OPENSEQ [absolutepath | seq.filename,record.id] [READONLY] TO seq.file.var
[ON ERROR statements] [LOCKED statements] {THEN statements [END]
| ELSE statements [END]}
OPENSEQ [absolutepath | seq.filename,record.id] [READONLY] TO seq.file.var
[LOCKED statements] [ON ERROR statements] {THEN statements [END]
| ELSE statements [END]}
Description
The UniBasic OPENSEQ command opens a sequential file for access,
starting at the specified record. UniData limits to 150 the number
of sequential files you can open in a UniBasic program.
It would seem your path uses the seq.filename, record.id format
instead of the absolute path format. e.g.
065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances\:FNAME TO
OUT.FILE ELSE
HTH (and fixes it).
Bill
Untitled Page
- Original Message -
*From:* adew...@stylmark.com
*To:* U2 Users List u2-users@listserver.u2ug.org
*Date:* 8/5/2013 7:17 AM
*Subject:* Re: [U2] OPENSEQ
I'm a Domain Admin so permissions is not an issue. I'm going back to the
beginning and start over. Maybe I have an issue I'm not seeing.
Thanks for all your help.
Albert DeWitt, CPIM
Sr. Programmer Analyst
Stylmark, Inc.
6536 Main St NE | Minneapolis MN 55432 | USA
DD: 763-574-8705 | PH: 763-574-7474 | F: 763-574-1415
adew...@stylmark.com
www.stylmark.com
Stylmark is a proud member of RDI, ARE, NGA
You can now find Stylmark on LinkedIn and Facebook
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org]
On Behalf Of bradley.sch...@usbank.com
Sent: Monday, August 05, 2013 9:10 AM
To: U2 Users List
Subject: Re: [U2] OPENSEQ
Does the code still fail with the dummy file out there? If not, I'd guess
permissions.
From: Al DeWitt adew...@stylmark.com
To: U2 Users List u2-users@listserver.u2ug.org,
Date: 08/05/2013 09:04 AM
Subject:Re: [U2] OPENSEQ
Sent by:u2-users-boun...@listserver.u2ug.org
Thanks for your reply Kevin.
I can list LRGLBRVARS at TCL. I put a dummy file inside to prove it.
FNAME does not exist. In the code I stole this from the name is created
anew each time. It always open the file empty, allows me to populate
and close it. However, in this code it's not working.
Since we're running SB+/SBClient I thought the '.XLS' extension was
causing issues (grasping at straws) but I'm getting the same errors.
Albert DeWitt, CPIM
Sr. Programmer Analyst
Stylmark, Inc.
6536 Main St NE | Minneapolis MN 55432 | USA
DD: 763-574-8705 | PH: 763-574-7474 | F: 763-574-1415
adew...@stylmark.com
www.stylmark.com
Stylmark is a proud member of RDI, ARE, NGA
You can now find Stylmark on LinkedIn and Facebook
-Original Message-
From: Kevin King [mailto:ke...@precisonline.com]
Sent: Monday, August 05, 2013 8:31 AM
To: U2 Users List
Subject: Re: [U2] OPENSEQ
I've never used OPENSEQ on a remote drive like that. I presume you can
LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the
OPENSEQ should work with that just fine. May I also presume that you
looed at FNAME and a file with that name really does exist in that
directory file?
On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt adew...@stylmark.com wrote:
Please educate me on OPENSEQ. I have some code that is giving me an
error. The funny thing is that I stole the code from a working program:
The code:
064: FNAME = 'LLV':FNAME:'.XLS'
065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME
Re: [U2] OPENSEQ
Ummm, if the file doesn't exist then it's *supposed* to take the else clause, when I'm creating new files I use THEN and put the abort in there. When you borrowed this code did it have all of the validation? I don't have my error codes handy - but if you let it continue does it let you do the writeseq? Hth Colin -Original Message- From: Al DeWitt Sent: Monday, August 05, 2013 8:04 AM To: U2 Users List Subject: Re: [U2] OPENSEQ Thanks for your reply Kevin. I can list LRGLBRVARS at TCL. I put a dummy file inside to prove it. FNAME does not exist. In the code I stole this from the name is created anew each time. It always open the file empty, allows me to populate and close it. However, in this code it's not working. Since we're running SB+/SBClient I thought the '.XLS' extension was causing issues (grasping at straws) but I'm getting the same errors. Albert DeWitt, CPIM Sr. Programmer Analyst Stylmark, Inc. -Original Message- From: Kevin King Sent: Monday, August 05, 2013 8:31 AM To: U2 Users List Subject: Re: [U2] OPENSEQ I've never used OPENSEQ on a remote drive like that. I presume you can LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the OPENSEQ should work with that just fine. May I also presume that you looed at FNAME and a file with that name really does exist in that directory file? On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt wrote: Please educate me on OPENSEQ. I have some code that is giving me an error. The funny thing is that I stole the code from a working program: The code: 064: FNAME = 'LLV':FNAME:'.XLS' 065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO OUT.FILE ELSE 066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE 067: ERRCD = STATUS() 068: GOSUB 900 069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is aborting.') 070: GO 071: END If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66 ERRCD = 0. According to manual 2 means: The file does not exist. A 0 means The record does not exist. In my voc file I have an entry for LRGLBRVARS. It looks like this: Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\led\fs-styl\Public\LrgLbrVariances 003: D_HOLD_ Bottom. What is OPENSEQ looking for and where does it expect it to find it? Thanks. Albert DeWitt, CPIM ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ
As I mentioned earlier I went back and started over. This is my Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\ServerName\ShareName\Folder\LrgLbrVariances 003: D_HOLD_ Bottom. My OPENSEQ statement is this: OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE NULL This opens my previously non-existing file, allows me to write to it and closes it. It does what I want it to. As I mentioned to someone else I have no idea why the above statement worked, but trying to error catching showed an error condition. Go figure. Albert DeWitt, CPIM Sr. Programmer Analyst Stylmark, Inc. 6536 Main St NE | Minneapolis MN 55432 | USA DD: 763-574-8705 | PH: 763-574-7474 | F: 763-574-1415 adew...@stylmark.com www.stylmark.com Stylmark is a proud member of RDI, ARE, NGA You can now find Stylmark on LinkedIn and Facebook -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Colin Alfke Sent: Monday, August 05, 2013 12:32 PM To: 'U2 Users List' Subject: Re: [U2] OPENSEQ Ummm, if the file doesn't exist then it's *supposed* to take the else clause, when I'm creating new files I use THEN and put the abort in there. When you borrowed this code did it have all of the validation? I don't have my error codes handy - but if you let it continue does it let you do the writeseq? Hth Colin -Original Message- From: Al DeWitt Sent: Monday, August 05, 2013 8:04 AM To: U2 Users List Subject: Re: [U2] OPENSEQ Thanks for your reply Kevin. I can list LRGLBRVARS at TCL. I put a dummy file inside to prove it. FNAME does not exist. In the code I stole this from the name is created anew each time. It always open the file empty, allows me to populate and close it. However, in this code it's not working. Since we're running SB+/SBClient I thought the '.XLS' extension was causing issues (grasping at straws) but I'm getting the same errors. Albert DeWitt, CPIM Sr. Programmer Analyst Stylmark, Inc. -Original Message- From: Kevin King Sent: Monday, August 05, 2013 8:31 AM To: U2 Users List Subject: Re: [U2] OPENSEQ I've never used OPENSEQ on a remote drive like that. I presume you can LIST LRGLBRVARS @ TCL without difficulty right? If so, I would think the OPENSEQ should work with that just fine. May I also presume that you looed at FNAME and a file with that name really does exist in that directory file? On Mon, Aug 5, 2013 at 7:10 AM, Al DeWitt wrote: Please educate me on OPENSEQ. I have some code that is giving me an error. The funny thing is that I stole the code from a working program: The code: 064: FNAME = 'LLV':FNAME:'.XLS' 065: OPENSEQ \\SERVER\SHARE-NAME\FOLDER-NAME\LrgLbrVariances,FNAME TO OUT.FILE ELSE 066: *OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE 067: ERRCD = STATUS() 068: GOSUB 900 069: CALL SB.DISP(3,'SFC9667 OPENSEQ Error: ':ERRMSG:' Program is aborting.') 070: GO 071: END If I run it as is ERRCD = 2. If I comment out 65 and uncomment 66 ERRCD = 0. According to manual 2 means: The file does not exist. A 0 means The record does not exist. In my voc file I have an entry for LRGLBRVARS. It looks like this: Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\ServerName\ShareName\Folder\LrgLbrVariances 003: D_HOLD_ Bottom. What is OPENSEQ looking for and where does it expect it to find it? Thanks. Albert DeWitt, CPIM ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ
What you're seeing is the correct behavior of OPENSEQ. I think what's causing the confusion is there are multiple error conditions possible when dealing with opening a flat file for writing. The non-existence of the file prior to opening may or may not be an error depending on your usage scenario, but it is important information, and using an error code along with the ELSE clause is the only way it can be conveyed. If you're writing a per-instance error log, for example, you might choose to loop through OPENSEQ statements and increment the ID until you hit the non-existence condition so you don't overwrite prior logs. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Al DeWitt Sent: Monday, August 05, 2013 11:03 AM To: U2 Users List Subject: Re: [U2] OPENSEQ As I mentioned earlier I went back and started over. This is my Top of LRGLBRVARS in VOC, 3 lines, 48 characters. 001: DIR 002: \\ServerName\ShareName\Folder\LrgLbrVariances 003: D_HOLD_ Bottom. My OPENSEQ statement is this: OPENSEQ LRGLBRVARS,FNAME TO OUT.FILE ELSE NULL This opens my previously non-existing file, allows me to write to it and closes it. It does what I want it to. As I mentioned to someone else I have no idea why the above statement worked, but trying to error catching showed an error condition. Go figure. Albert DeWitt, CPIM Sr. Programmer Analyst Stylmark, Inc. 6536 Main St NE | Minneapolis MN 55432 | USA DD: 763-574-8705 | PH: 763-574-7474 | F: 763-574-1415 adew...@stylmark.com www.stylmark.com Stylmark is a proud member of RDI, ARE, NGA You can now find Stylmark on LinkedIn and Facebook ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ
From: Al DeWitt I'm a Domain Admin so permissions is not an issue. I understand the sentiment there but we may not be aware of the permissions required for the operation in question, so it's tough to know if the right permissions have not been granted. My related experiences, dunno if this helps anyone... Some products need their own access to remote data resources. The permissions of the current user, especially telnet, are not used to access remote resource, because it's the DBMS not the user that is doing the access. Most sites don't run their DBMS services with Administrator privs - that's a huge security issue. (I can just see people now going huh? really? and checking their services ... go ahead, we'll be here when you get back...) I'll sometimes temporarily open full permissions to the target and give admin privs to the client application just to see if that resolves the issue. You'd be surprised at how often this does reveal a permissions issue - but again you shouldn't leave it like that because this is a huge security issue. NOT being a domain admin I usually have issues getting the right restricted permissions back so I always try to have someone else handy to fix it. :) I also use Sysinternals tools to find out exactly what the system is trying to do. Maybe in this OpenSEQ case it's not actually reading from the intended target. Again, you might be surprised at all of the disk reads that need to be done to get to the real data you're trying to access. This could help to identify performance issues too. http://technet.microsoft.com/en-us/sysinternals/bb795533.aspx HTH T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ / WRITESEQ and UniObjects
I don't know if we have enough information. Does it start? No output whatsoever? IIRC, you can tell writeseq not to cache and to write to disk immediately. On Fri, Nov 4, 2011 at 3:03 PM, Holt, Jake jh...@samsill.com wrote: I wrote a program to export some data using openseq/writeseq (to a local server drive, tried a UNC path too) and it works perfectly until I try to call it using UniObjects. Is this normal behavior? If so, anyway to make it work with UniObjects? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ / WRITESEQ and UniObjects
It fails to write. It gives the failure to open error as well, but I believe that is fairly standard if the file doesn't exist before hand. It operations normally, just doesn't write the records to the file. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow Sent: Friday, November 04, 2011 2:11 PM To: U2 Users List Subject: Re: [U2] OPENSEQ / WRITESEQ and UniObjects I don't know if we have enough information. Does it start? No output whatsoever? IIRC, you can tell writeseq not to cache and to write to disk immediately. On Fri, Nov 4, 2011 at 3:03 PM, Holt, Jake jh...@samsill.com wrote: I wrote a program to export some data using openseq/writeseq (to a local server drive, tried a UNC path too) and it works perfectly until I try to call it using UniObjects. Is this normal behavior? If so, anyway to make it work with UniObjects? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ / WRITESEQ and UniObjects
I'd guess it was some type of permission error. Does the user you are connecting with through UniObjects have write permissions on the folder that the open/writeseq is writing on? hth Colin Alfke Calgary, Canada -Original Message- From: Holt, Jake It fails to write. It gives the failure to open error as well, but I believe that is fairly standard if the file doesn't exist before hand. It operations normally, just doesn't write the records to the file. -Original Message- From: Steve Romanow I don't know if we have enough information. Does it start? No output whatsoever? IIRC, you can tell writeseq not to cache and to write to disk immediately. On Fri, Nov 4, 2011 at 3:03 PM, Holt, Jake wrote: I wrote a program to export some data using openseq/writeseq (to a local server drive, tried a UNC path too) and it works perfectly until I try to call it using UniObjects. Is this normal behavior? If so, anyway to make it work with UniObjects? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ / WRITESEQ and UniObjects
I typically will throw a touch filename before the openseq. does the uniobjects user have permissions on the disk? Maybe try something innocuous to see if the job is executing at all. On Fri, Nov 4, 2011 at 3:27 PM, Holt, Jake jh...@samsill.com wrote: It fails to write. It gives the failure to open error as well, but I believe that is fairly standard if the file doesn't exist before hand. It operations normally, just doesn't write the records to the file. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow Sent: Friday, November 04, 2011 2:11 PM To: U2 Users List Subject: Re: [U2] OPENSEQ / WRITESEQ and UniObjects I don't know if we have enough information. Does it start? No output whatsoever? IIRC, you can tell writeseq not to cache and to write to disk immediately. On Fri, Nov 4, 2011 at 3:03 PM, Holt, Jake jh...@samsill.com wrote: I wrote a program to export some data using openseq/writeseq (to a local server drive, tried a UNC path too) and it works perfectly until I try to call it using UniObjects. Is this normal behavior? If so, anyway to make it work with UniObjects? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ / WRITESEQ and UniObjects
It was a permission issue -- I blame Friday. Thanks. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Colin Alfke Sent: Friday, November 04, 2011 2:31 PM To: 'U2 Users List' Subject: Re: [U2] OPENSEQ / WRITESEQ and UniObjects I'd guess it was some type of permission error. Does the user you are connecting with through UniObjects have write permissions on the folder that the open/writeseq is writing on? hth Colin Alfke Calgary, Canada -Original Message- From: Holt, Jake It fails to write. It gives the failure to open error as well, but I believe that is fairly standard if the file doesn't exist before hand. It operations normally, just doesn't write the records to the file. -Original Message- From: Steve Romanow I don't know if we have enough information. Does it start? No output whatsoever? IIRC, you can tell writeseq not to cache and to write to disk immediately. On Fri, Nov 4, 2011 at 3:03 PM, Holt, Jake wrote: I wrote a program to export some data using openseq/writeseq (to a local server drive, tried a UNC path too) and it works perfectly until I try to call it using UniObjects. Is this normal behavior? If so, anyway to make it work with UniObjects? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and the LOCKED Option
Please provide the exact source, and the exact compilation error message -Original Message- From: Al DeWitt adew...@stylmark.com To: u2-users u2-users@listserver.u2ug.org Sent: Fri, Oct 28, 2011 2:21 pm Subject: [U2] OPENSEQ and the LOCKED Option Unidata 7.1.20 ECLTYPE P Whenever I try to include the LOCKED option in the OPENSEQ statement my est program does not compile. If I leave it out it does compile. When two users run this program one executes the OPENSEQ command and the ther appears hung...no message, nothing. When the first user closes he file the second user continues on. Since LOCKED appeared to allow me to tell the other users that the file s locked and not to give up hope what do you folks do to get around his dilemma? Thanks. Al ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and the LOCKED Option
I've usually only used it where I expect one user to be accessing the file at a time anyway. However, it should (mine does on UD 7.1.6) compile. You are using an END before the next THEN or ELSE - that might do it. hth Colin Alfke Calgary, Canada -Original Message- From: Al DeWitt Unidata 7.1.20 ECLTYPE P Whenever I try to include the LOCKED option in the OPENSEQ statement my test program does not compile. If I leave it out it does compile. When two users run this program one executes the OPENSEQ command and the other appears hung...no message, nothing. When the first user closes the file the second user continues on. Since LOCKED appeared to allow me to tell the other users that the file is locked and not to give up hope what do you folks do to get around this dilemma? Thanks. Al ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and the LOCKED Option
Here is my admittedly simple test program and the results: 001: IMPORT.FILE = FILE_IN.CSV 002: CLOSE.IT = 1 003: OPENSEQ DELTAIMPORT,IMPORT.FILE TO FILEIN 004: LOCKED 005: CRT 'FILE IS LOCKED BY SOMEONE ELSE' ; DUMMY='' ; INPUT DUMMY 006: ELSE 007: ERR.CD = STATUS() 008: CRT 'ERROR CODE=':ERR.CD ; DUMMY='' ; INPUT DUMMY 009: CLOSE.IT = 0 010: END 011: IF CLOSE.IT THEN 012: CRT 'HOORAY, FILE_IN IS OPENED' ; DUMMY='' ; INPUT DUMMY 013: CLOSESEQ FILEIN 014: END 015: END *--: FIB Filed ALD1 in file BP. Compiling Unibasic: ..\..\..\FLOPROGS\DEV\DEV.IIBASE8\BP8.0\ALD1 in mode 'p'. main program: syntax error at or before line 16 EOF ^ Expecting: ELSE compilation failed It works fine if I take out lines 4 - 5. Al DeWitt -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Friday, October 28, 2011 4:39 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OPENSEQ and the LOCKED Option Please provide the exact source, and the exact compilation error message -Original Message- From: Al DeWitt adew...@stylmark.com To: u2-users u2-users@listserver.u2ug.org Sent: Fri, Oct 28, 2011 2:21 pm Subject: [U2] OPENSEQ and the LOCKED Option Unidata 7.1.20 ECLTYPE P Whenever I try to include the LOCKED option in the OPENSEQ statement my est program does not compile. If I leave it out it does compile. When two users run this program one executes the OPENSEQ command and the ther appears hung...no message, nothing. When the first user closes he file the second user continues on. Since LOCKED appeared to allow me to tell the other users that the file s locked and not to give up hope what do you folks do to get around his dilemma? Thanks. Al ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and the LOCKED Option
You need to change line 6 to END ELSE (to end the locked clause) -Original Message- From: Al DeWitt Here is my admittedly simple test program and the results: 001: IMPORT.FILE = FILE_IN.CSV 002: CLOSE.IT = 1 003: OPENSEQ DELTAIMPORT,IMPORT.FILE TO FILEIN 004: LOCKED 005: CRT 'FILE IS LOCKED BY SOMEONE ELSE' ; DUMMY='' ; INPUT DUMMY 006: ELSE 007: ERR.CD = STATUS() 008: CRT 'ERROR CODE=':ERR.CD ; DUMMY='' ; INPUT DUMMY 009: CLOSE.IT = 0 010: END 011: IF CLOSE.IT THEN 012: CRT 'HOORAY, FILE_IN IS OPENED' ; DUMMY='' ; INPUT DUMMY 013: CLOSESEQ FILEIN 014: END 015: END *--: FIB Filed ALD1 in file BP. Compiling Unibasic: ..\..\..\FLOPROGS\DEV\DEV.IIBASE8\BP8.0\ALD1 in mode 'p'. main program: syntax error at or before line 16 EOF ^ Expecting: ELSE compilation failed It works fine if I take out lines 4 - 5. Al DeWitt ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and the LOCKED Option
That did it! Thank you very much. Al DeWitt -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Colin Alfke Sent: Friday, October 28, 2011 5:01 PM To: 'U2 Users List' Subject: Re: [U2] OPENSEQ and the LOCKED Option You need to change line 6 to END ELSE (to end the locked clause) -Original Message- From: Al DeWitt Here is my admittedly simple test program and the results: 001: IMPORT.FILE = FILE_IN.CSV 002: CLOSE.IT = 1 003: OPENSEQ DELTAIMPORT,IMPORT.FILE TO FILEIN 004: LOCKED 005: CRT 'FILE IS LOCKED BY SOMEONE ELSE' ; DUMMY='' ; INPUT DUMMY 006: ELSE 007: ERR.CD = STATUS() 008: CRT 'ERROR CODE=':ERR.CD ; DUMMY='' ; INPUT DUMMY 009: CLOSE.IT = 0 010: END 011: IF CLOSE.IT THEN 012: CRT 'HOORAY, FILE_IN IS OPENED' ; DUMMY='' ; INPUT DUMMY 013: CLOSESEQ FILEIN 014: END 015: END *--: FIB Filed ALD1 in file BP. Compiling Unibasic: ..\..\..\FLOPROGS\DEV\DEV.IIBASE8\BP8.0\ALD1 in mode 'p'. main program: syntax error at or before line 16 EOF ^ Expecting: ELSE compilation failed It works fine if I take out lines 4 - 5. Al DeWitt ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
Wol In BASIC, *EVERYTHING* is a string (apart from file variables). Therefore any comparison should be valid. To be more precise, no. UniVerse Basic is a run-time typed language (like PHP) not a string language. So it gets the performance and storage benefits of real types, and coerces between types under the cover. If you say For I = 1 To 10, and examine I in the debugger, you will see that it is an integer, not a string. If you later say I=FRED it will be coerced into a string, as will I := FRED or I2 = FRED. In addition to file variables, there are plenty other structures that are not coercible into strings: select list handles (from EXECUTE statement, SELECT. SOMELIST), XML DOM handles and BCI context handles to name but a few. It may seem pedantic, but these distinctions are important when selling the benefits of language like UniVerse Basic. The word 'untyped' offends some sectors of the programming community. 'run-time typed' is generally more acceptable. (and it's funny how many developers sneer at the first mention of these, until you follow up with the PHP analogy.. and suddenly they see the light). Brian ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
If your file is opened, then comparing it to an empty string is what will cause an invalid data type error. WHY!!! If the datatypes don't match, then the result of the comparison is FALSE, not INVALID. It is logically correct to do such a comparison. The result I am looking for is the logically correct response. It SHOULD NOT crash the program! And it worked fine on INFORMATION, why not UV? It is a bad idea to allow it, it encourages bad programming practices and it can hide a bug in your program for example if you do: READ CAR FROM CARS ELSE CAR = '' IF CARS # '' THEN Here what was intended was to compare CAR to '' not CARS but having the S there is a typo. If we don't allow datatypes of different types being compared this bug has a greater chance of getting caught during development because the program will fail on comparing the file to a null string. If you use FILEINFO it shows that you know that the variable you are testing is a file. I've seen a similar case where a subroutine was expecting: SUBROUTINE ABC (MAT A, MAT B, MAT C) A programmer only needed the contents of the matrix B and C to call it and did: CALL ABC(,MAT B, MAT C) Only thing Matrix ABC puts something in MAT A and since the programmer passed an empty string what happens is that the content of Matrix B is over-written causing data corruption. It would probably have been a good idea to detect that since a Matrix was expected, it shouldn't be legal to pass a dynamic array to the subroutine. Most modern OOP programming languages don't allow for types of different kinds to be compared to one another without some way of casting them. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
In message 321088.49154...@web36901.mail.mud.yahoo.com, Jacques G. jacque...@yahoo.com writes If your file is opened, then comparing it to an empty string is what will cause an invalid data type error. WHY!!! If the datatypes don't match, then the result of the comparison is FALSE, not INVALID. It is logically correct to do such a comparison. The result I am looking for is the logically correct response. It SHOULD NOT crash the program! And it worked fine on INFORMATION, why not UV? It is a bad idea to allow it, it encourages bad programming practices and it can hide a bug in your program for example if you do: READ CAR FROM CARS ELSE CAR = '' IF CARS # '' THEN Here what was intended was to compare CAR to '' not CARS but having the S there is a typo. If we don't allow datatypes of different types being compared this bug has a greater chance of getting caught during development because the program will fail on comparing the file to a null string. If you use FILEINFO it shows that you know that the variable you are testing is a file. The big problem with your attitude is that you are assuming a typed language - and even then it's invalid. In BASIC, *EVERYTHING* is a string (apart from file variables). Therefore any comparison should be valid. And, using your own words against you - it shows that you know that the variable you are testing is a file. What if I DON'T know (which is why I was doing the test!). At the end of the day, an IF test for equality should return FALSE on a type mismatch, not CRASH. Because FALSE is the *correct* answer. That's what I absolutely HATE about artificial stupidity. It thinks it knows better than me, and gives me what it thinks I should have, not what I asked for. Cheers, Wol -- Anthony W. Youngman pi...@thewolery.demon.co.uk 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
I know what you're saying, but just to make sure we're precise I'll add a footnote. The run-time machine doesn't have to find additional memory *each* time you add to a dynamic array (as you said perhaps just imprecisely). Rather, your workspace arrays have certain fixed sizes and it's only when you go over this size that it will allocate you a new larger area and move the array there. So for example, you get slots that are 50 bytes, 250 bytes, and so on, probably implementation dependent. The run-time machine will allocate you a smaller area at first, until it knows you need a bigger one. Alternatively, garbage collection will return to the available pool, the no longer used space for arrays that have shrunk. I never did any testing to see if the garbage collector actually works *while* your program is running or only after the signal that the program is now finished. I do agree however with the observation that reading a large amount of data into a dynamic array is *most likely* causing the run-time machine to allocate you the entire size of that data in your own *workspace*. Danger Will Robinson! Warning! Warning! When it runs out of memory/disk will it wait forever? Or will it halt the system? Try again later, answer fuzzy. Will Johnson -Original Message- From: John Hester jhes...@momtex.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue, May 18, 2010 12:31 pm Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Reading my own response just made me realize what's going on. I think Jerry's response was right. I remember many years ago (I won't say how many) when we were on much slower hardware, explaining to a coworker that it was better to use dimensioned arrays when possible because they were faster to populate than dynamic arrays. The reason they're faster is because the necessary space for them is already reserved in memory. A dynamic array has to go out and find add'l memory each time you add to it. Looks like putting a sequential file in a dimensioned array makes it go out and reserve a block of memory the size of the entire file. If that's the case then making FILEVARS a dynamic array *should* work. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Hester Sent: Tuesday, May 18, 2010 11:42 AM To: U2 Users List Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Yes, I see your point. I wonder if the integer gets treated like a string in the first instance. I wonder what the result with FILEVARS1 would be. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Anthony W. Youngman Sent: Tuesday, May 18, 2010 7:45 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OPENSEQ and Abnormal termination of UV In message e6179e13392ec14aabcd5272c3aedd61124ec...@exchangesvr.momtex.com, John Hester jhes...@momtex.com writes I think it's something along those lines, but I don't think it's trying to stick the entire contents of the file into a variable. What I think OPENSEQ is doing is keeping track of the position where the EOF mark is so it will know when the end of the file is reached. For a file greater than 2GB in size, this position is an integer that takes more than 32 bits to store. UV, being a 32-bit application, is not going to be able to handle it. The maximum positive integer value a 32-bit application can reference is 2147483647. The problem is, FV.FILE and FILEVARS(1) are *allegedly* *functionally* *identical*. An element of a dimensioned array, is supposed to be a normal variable in every way shape or form. The problem is that, in this instance, it clearly isn't because the variable works while the element (allegedly identical) causes a crash. I'd agree with Perry. It's a bug. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
...That's what I absolutely HATE about artificial stupidity. It thinks it knows better than me, and gives me what it thinks I should have, not what I asked for. Then again, I can't imagine it thinks it should CRASH! :-o Bill Anthony W. Youngman said the following on 5/21/2010 5:15 PM: In message 321088.49154...@web36901.mail.mud.yahoo.com, Jacques G. jacque...@yahoo.com writes [snipped] [snipped] At the end of the day, an IF test for equality should return FALSE on a type mismatch, not CRASH. Because FALSE is the *correct* answer. That's what I absolutely HATE about artificial stupidity. It thinks it knows better than me, and gives me what it thinks I should have, not what I asked for. Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
Oh - that reminds me of something else I'd call a bug. It might well have been fixed by now (I met it in 9.6) but you couldn't safely use a file variable in an IF statement. Can't remember the details, but it was something like FVAR = some conditional code OPEN FILE TO FVAR more code IF FVAR EQ THEN oh the file isn't open, so do whatever If your file is opened, then comparing it to an empty string is what will cause an invalid data type error. You want to do instead: IF FILEINFO(FVAR,0) = 0 THEN Or: OPEN FILE TO FVAR THEN FLAG.OPEN = 1 ELSE FLAG.OPEN = 0 IF FLAG.OPEN THEN One error I've seen: READ CUSTOMER FROM CUSTOMER THEN... The record item that is being read is the same name as the opened file variable... ouch ! ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
Using dimmed matrixes is still a lot faster. If you have a dynamic array of 10,000 items and you wantA9995 when you extract it, it will parse the whole until it passes 9994 @AM then it will extract whatever is between the 9994 and 9995. Having it in a dynamic array is like having a pointer to each @AM position. This is why the REMOVE command was added for when a dynamic array is processed within a for loop. The REMOVE command keeps track of the position of the last AM, VM, SVM used. One exemple: DIM B(10) A = CONVERT(],@AM,AA]BB]]) MATPARSE B FROM A USING @AM B now has a pointer to each of the 4 elements of 4: B(1) - AA B(2) - B B(3) - B(4) - When you want the third row, you don't have to pass through the contents of B(1) and B(2) you have a pointer to the start of the string that contains . I've used dimmed matrixes to speed sorts and binary search algorithms. One other advantage of a dimmed matrix is that you can use it to pass several files as arguments to a subroutine. With a dynamic array it can only be a file or a string. You don't change a subroutine's signature if you pass call MYSUB(MAT FILES,MAT ARGV_IN, MAT ARGV_OUT) This way you can add to the number of files and arguments of a subroutine without changing the number of arguments. With dynamic arrays you would have to add more arguments to add more files. Ei from: CALL MYSUB(FILE1, ARGV_IN, ARGV_OUT) to CALL MYSUB(FILE1, FILE2, ARGV_IN, ARGV_OUT) This means each program calling MYSUB has to be modified. - Original Message From: John Hester jhes...@momtex.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue, May 18, 2010 3:31:25 PM Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Reading my own response just made me realize what's going on. I think Jerry's response was right. I remember many years ago (I won't say how many) when we were on much slower hardware, explaining to a coworker that it was better to use dimensioned arrays when possible because they were faster to populate than dynamic arrays. The reason they're faster is because the necessary space for them is already reserved in memory. A dynamic array has to go out and find add'l memory each time you add to it. Looks like putting a sequential file in a dimensioned array makes it go out and reserve a block of memory the size of the entire file. If that's the case then making FILEVARS a dynamic array *should* work. -John ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
In message 536051.22442...@web36905.mail.mud.yahoo.com, Jacques G. jacque...@yahoo.com writes Oh - that reminds me of something else I'd call a bug. It might well have been fixed by now (I met it in 9.6) but you couldn't safely use a file variable in an IF statement. Can't remember the details, but it was something like FVAR = some conditional code OPEN FILE TO FVAR more code IF FVAR EQ THEN oh the file isn't open, so do whatever If your file is opened, then comparing it to an empty string is what will cause an invalid data type error. WHY!!! If the datatypes don't match, then the result of the comparison is FALSE, not INVALID. It is logically correct to do such a comparison. The result I am looking for is the logically correct response. It SHOULD NOT crash the program! And it worked fine on INFORMATION, why not UV? Cheers, Wol -- Anthony W. Youngman pi...@thewolery.demon.co.uk 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
Anthony W. Youngman pi...@thewolery.demon.co.uk 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick Anthony, Did you know that clicking on your maverick link in your signature brings up the janitor's warehouse website? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
Yes, I see your point. I wonder if the integer gets treated like a string in the first instance. I wonder what the result with FILEVARS1 would be. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Anthony W. Youngman Sent: Tuesday, May 18, 2010 7:45 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OPENSEQ and Abnormal termination of UV In message e6179e13392ec14aabcd5272c3aedd61124ec...@exchangesvr.momtex.com, John Hester jhes...@momtex.com writes I think it's something along those lines, but I don't think it's trying to stick the entire contents of the file into a variable. What I think OPENSEQ is doing is keeping track of the position where the EOF mark is so it will know when the end of the file is reached. For a file greater than 2GB in size, this position is an integer that takes more than 32 bits to store. UV, being a 32-bit application, is not going to be able to handle it. The maximum positive integer value a 32-bit application can reference is 2147483647. The problem is, FV.FILE and FILEVARS(1) are *allegedly* *functionally* *identical*. An element of a dimensioned array, is supposed to be a normal variable in every way shape or form. The problem is that, in this instance, it clearly isn't because the variable works while the element (allegedly identical) causes a crash. I'd agree with Perry. It's a bug. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
Reading my own response just made me realize what's going on. I think Jerry's response was right. I remember many years ago (I won't say how many) when we were on much slower hardware, explaining to a coworker that it was better to use dimensioned arrays when possible because they were faster to populate than dynamic arrays. The reason they're faster is because the necessary space for them is already reserved in memory. A dynamic array has to go out and find add'l memory each time you add to it. Looks like putting a sequential file in a dimensioned array makes it go out and reserve a block of memory the size of the entire file. If that's the case then making FILEVARS a dynamic array *should* work. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Hester Sent: Tuesday, May 18, 2010 11:42 AM To: U2 Users List Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Yes, I see your point. I wonder if the integer gets treated like a string in the first instance. I wonder what the result with FILEVARS1 would be. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Anthony W. Youngman Sent: Tuesday, May 18, 2010 7:45 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OPENSEQ and Abnormal termination of UV In message e6179e13392ec14aabcd5272c3aedd61124ec...@exchangesvr.momtex.com, John Hester jhes...@momtex.com writes I think it's something along those lines, but I don't think it's trying to stick the entire contents of the file into a variable. What I think OPENSEQ is doing is keeping track of the position where the EOF mark is so it will know when the end of the file is reached. For a file greater than 2GB in size, this position is an integer that takes more than 32 bits to store. UV, being a 32-bit application, is not going to be able to handle it. The maximum positive integer value a 32-bit application can reference is 2147483647. The problem is, FV.FILE and FILEVARS(1) are *allegedly* *functionally* *identical*. An element of a dimensioned array, is supposed to be a normal variable in every way shape or form. The problem is that, in this instance, it clearly isn't because the variable works while the element (allegedly identical) causes a crash. I'd agree with Perry. It's a bug. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
Surely it is just a pointer to the file and the position in that file - i open many multi gigabyte files using openseq and i would not expect the udt process to allocate tens of Gig at that time for the readseq operations ... It should be a tiny piece of memory to act as a pointer !! ?? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Hester Sent: 18 May 2010 20:31 To: U2 Users List Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Reading my own response just made me realize what's going on. I think Jerry's response was right. I remember many years ago (I won't say how many) when we were on much slower hardware, explaining to a coworker that it was better to use dimensioned arrays when possible because they were faster to populate than dynamic arrays. The reason they're faster is because the necessary space for them is already reserved in memory. A dynamic array has to go out and find add'l memory each time you add to it. Looks like putting a sequential file in a dimensioned array makes it go out and reserve a block of memory the size of the entire file. If that's the case then making FILEVARS a dynamic array *should* work. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Hester Sent: Tuesday, May 18, 2010 11:42 AM To: U2 Users List Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Yes, I see your point. I wonder if the integer gets treated like a string in the first instance. I wonder what the result with FILEVARS1 would be. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Anthony W. Youngman Sent: Tuesday, May 18, 2010 7:45 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OPENSEQ and Abnormal termination of UV In message e6179e13392ec14aabcd5272c3aedd61124ec...@exchangesvr.momtex.com, John Hester jhes...@momtex.com writes I think it's something along those lines, but I don't think it's trying to stick the entire contents of the file into a variable. What I think OPENSEQ is doing is keeping track of the position where the EOF mark is so it will know when the end of the file is reached. For a file greater than 2GB in size, this position is an integer that takes more than 32 bits to store. UV, being a 32-bit application, is not going to be able to handle it. The maximum positive integer value a 32-bit application can reference is 2147483647. The problem is, FV.FILE and FILEVARS(1) are *allegedly* *functionally* *identical*. An element of a dimensioned array, is supposed to be a normal variable in every way shape or form. The problem is that, in this instance, it clearly isn't because the variable works while the element (allegedly identical) causes a crash. I'd agree with Perry. It's a bug. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
Only the UV or UD developers could say for sure, but I'd venture to guess that multi-gigabyte sequential files weren't envisioned when the dimensioned array code was written. Maybe there's never been a request to revisit it. I quit using dimensioned arrays probably around the late 90's when faster hardware seemed to negate any performance advantage. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Symeon Breen Sent: Tuesday, May 18, 2010 12:59 PM To: 'U2 Users List' Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Surely it is just a pointer to the file and the position in that file - i open many multi gigabyte files using openseq and i would not expect the udt process to allocate tens of Gig at that time for the readseq operations ... It should be a tiny piece of memory to act as a pointer !! ?? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of John Hester Sent: 18 May 2010 20:31 To: U2 Users List Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Reading my own response just made me realize what's going on. I think Jerry's response was right. I remember many years ago (I won't say how many) when we were on much slower hardware, explaining to a coworker that it was better to use dimensioned arrays when possible because they were faster to populate than dynamic arrays. The reason they're faster is because the necessary space for them is already reserved in memory. A dynamic array has to go out and find add'l memory each time you add to it. Looks like putting a sequential file in a dimensioned array makes it go out and reserve a block of memory the size of the entire file. If that's the case then making FILEVARS a dynamic array *should* work. -John ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
Looks like putting a sequential file in a dimensioned array makes it go out and reserve a block of memory the size of the entire file. Doubtful.. I'm guessing under the hood the array will resolve to a series of pointers somewhere down the track, but those pointers will need to be cast to different types depending on what is being stored in the array - a variable, a file pointer, a sequential file pointer etc. So something in that cast will be wrong - it might for example be that whatever structure controls a sequential file originally contained a 32 bit address and now doesn't but the cast is still expecting that, or that it gets copied with an alignment change or something similar. In other words, typical C bug from a pretty unlikely occurrence. Brian ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
In message e6179e13392ec14aabcd5272c3aedd61124ed...@exchangesvr.momtex.com, John Hester jhes...@momtex.com writes Yes, I see your point. I wonder if the integer gets treated like a string in the first instance. I wonder what the result with FILEVARS1 would be. Illegal assignment. You can't store a file descriptor in a dynamic array, because it's not a character string (it MIGHT be implemented as such, but it doesn't make sense to treat it as such, so it's a logical stupidity. I don't know of any MV implementation that permits this). Cheers, Wol -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Anthony W. Youngman Sent: Tuesday, May 18, 2010 7:45 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OPENSEQ and Abnormal termination of UV In message e6179e13392ec14aabcd5272c3aedd61124ec...@exchangesvr.momtex.com, John Hester jhes...@momtex.com writes I think it's something along those lines, but I don't think it's trying to stick the entire contents of the file into a variable. What I think OPENSEQ is doing is keeping track of the position where the EOF mark is so it will know when the end of the file is reached. For a file greater than 2GB in size, this position is an integer that takes more than 32 bits to store. UV, being a 32-bit application, is not going to be able to handle it. The maximum positive integer value a 32-bit application can reference is 2147483647. The problem is, FV.FILE and FILEVARS(1) are *allegedly* *functionally* *identical*. An element of a dimensioned array, is supposed to be a normal variable in every way shape or form. The problem is that, in this instance, it clearly isn't because the variable works while the element (allegedly identical) causes a crash. I'd agree with Perry. It's a bug. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Anthony W. Youngman pi...@thewolery.demon.co.uk 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 Visit the MaVerick web-site - http://www.maverick-dbms.org Open Source Pick ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
Just for giggles... what happens if you... OPENSEQ '/tmp/file.txt' TO FV.TEMP ELSE ... FILEVARS(1) = FV.TEMP ?? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rajesh Menon Sent: Monday, May 17, 2010 2:56 PM To: u2-users@listserver.u2ug.org Subject: [U2] OPENSEQ and Abnormal termination of UV Does anyone knows what is happening here: I am trying to open a text file (over 4Gb) using OPENSEQ and storing the file variable into a array as follows: COMMON /MYPROG/ FILEVARS(10) OPENSEQ /tmp/file.txt to FILEVARS(1) ELSE ... This operation results abnormal termination with fault type error 11. Fault occurred at address 1c (which is the OPENSEQ command.). If the file size is less than 2147483647 bytes (2Gb), it works. Opening the same file using a scalar file variable always work irrespective of the file size. OPENSEQ /tmp/file.txt TO FV.FILE ELSE ... Any reason why the first method failing for +2Gb files? Any workarounds? Universe: 10.2.7 AIX: 5.3 Thanks Rajesh Menon ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
You may want to check with your Systems Administrator to be sure your file system is setup to support files larger than 2gig - Original Message - From: u2-users-boun...@listserver.u2ug.org u2-users-boun...@listserver.u2ug.org To: u2-users@listserver.u2ug.org u2-users@listserver.u2ug.org Sent: Mon May 17 14:55:30 2010 Subject: [U2] OPENSEQ and Abnormal termination of UV Does anyone knows what is happening here: I am trying to open a text file (over 4Gb) using OPENSEQ and storing the file variable into a array as follows: COMMON /MYPROG/ FILEVARS(10) OPENSEQ /tmp/file.txt to FILEVARS(1) ELSE ... This operation results abnormal termination with fault type error 11. Fault occurred at address 1c (which is the OPENSEQ command.). If the file size is less than 2147483647 bytes (2Gb), it works. Opening the same file using a scalar file variable always work irrespective of the file size. OPENSEQ /tmp/file.txt TO FV.FILE ELSE ... Any reason why the first method failing for +2Gb files? Any workarounds? Universe: 10.2.7 AIX: 5.3 Thanks Rajesh Menon ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
I already tried that. Same Error and the fault occurring at FILEVAR(1) = FV.TEMP line. Thanks, Rajesh -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor Sent: Monday, May 17, 2010 11:59 AM To: U2 Users List Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Just for giggles... what happens if you... OPENSEQ '/tmp/file.txt' TO FV.TEMP ELSE ... FILEVARS(1) = FV.TEMP ?? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rajesh Menon Sent: Monday, May 17, 2010 2:56 PM To: u2-users@listserver.u2ug.org Subject: [U2] OPENSEQ and Abnormal termination of UV Does anyone knows what is happening here: I am trying to open a text file (over 4Gb) using OPENSEQ and storing the file variable into a array as follows: COMMON /MYPROG/ FILEVARS(10) OPENSEQ /tmp/file.txt to FILEVARS(1) ELSE ... This operation results abnormal termination with fault type error 11. Fault occurred at address 1c (which is the OPENSEQ command.). If the file size is less than 2147483647 bytes (2Gb), it works. Opening the same file using a scalar file variable always work irrespective of the file size. OPENSEQ /tmp/file.txt TO FV.FILE ELSE ... Any reason why the first method failing for +2Gb files? Any workarounds? Universe: 10.2.7 AIX: 5.3 Thanks Rajesh Menon ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
Yes file system is setup to support +2Gb files. As I mentioned I can open the file using a scalar file variable. Problem happening only with the combination of +2Gb and using array variable. Thanks, Rajesh -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble Sent: Monday, May 17, 2010 12:00 PM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] OPENSEQ and Abnormal termination of UV You may want to check with your Systems Administrator to be sure your file system is setup to support files larger than 2gig - Original Message - From: u2-users-boun...@listserver.u2ug.org u2-users-boun...@listserver.u2ug.org To: u2-users@listserver.u2ug.org u2-users@listserver.u2ug.org Sent: Mon May 17 14:55:30 2010 Subject: [U2] OPENSEQ and Abnormal termination of UV Does anyone knows what is happening here: I am trying to open a text file (over 4Gb) using OPENSEQ and storing the file variable into a array as follows: COMMON /MYPROG/ FILEVARS(10) OPENSEQ /tmp/file.txt to FILEVARS(1) ELSE ... This operation results abnormal termination with fault type error 11. Fault occurred at address 1c (which is the OPENSEQ command.). If the file size is less than 2147483647 bytes (2Gb), it works. Opening the same file using a scalar file variable always work irrespective of the file size. OPENSEQ /tmp/file.txt TO FV.FILE ELSE ... Any reason why the first method failing for +2Gb files? Any workarounds? Universe: 10.2.7 AIX: 5.3 Thanks Rajesh Menon ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
I far as I know. The OPENSEQ statement requires both a file name and a record name. (i.e.: OPENSEQ DATA.DIRECTORY, FLAT.FILE.NAME TO F.TEMP ELSE ...) HTH -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rajesh Menon Sent: Monday, May 17, 2010 2:09 PM To: U2 Users List Subject: Re: [U2] OPENSEQ and Abnormal termination of UV I already tried that. Same Error and the fault occurring at FILEVAR(1) = FV.TEMP line. Thanks, Rajesh -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Perry Taylor Sent: Monday, May 17, 2010 11:59 AM To: U2 Users List Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Just for giggles... what happens if you... OPENSEQ '/tmp/file.txt' TO FV.TEMP ELSE ... FILEVARS(1) = FV.TEMP ?? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rajesh Menon Sent: Monday, May 17, 2010 2:56 PM To: u2-users@listserver.u2ug.org Subject: [U2] OPENSEQ and Abnormal termination of UV Does anyone knows what is happening here: I am trying to open a text file (over 4Gb) using OPENSEQ and storing the file variable into a array as follows: COMMON /MYPROG/ FILEVARS(10) OPENSEQ /tmp/file.txt to FILEVARS(1) ELSE ... This operation results abnormal termination with fault type error 11. Fault occurred at address 1c (which is the OPENSEQ command.). If the file size is less than 2147483647 bytes (2Gb), it works. Opening the same file using a scalar file variable always work irrespective of the file size. OPENSEQ /tmp/file.txt TO FV.FILE ELSE ... Any reason why the first method failing for +2Gb files? Any workarounds? Universe: 10.2.7 AIX: 5.3 Thanks Rajesh Menon ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
Let me see, can it be because you are trying to cram over 4 GB of data into a single cell. Unlike the OPEN statement that just puts the file variable into a variable, the OPENSEQ opens the whole file to the variable. Jerry Banker -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rajesh Menon Sent: Monday, May 17, 2010 1:56 PM To: u2-users@listserver.u2ug.org Subject: [U2] OPENSEQ and Abnormal termination of UV Does anyone knows what is happening here: I am trying to open a text file (over 4Gb) using OPENSEQ and storing the file variable into a array as follows: COMMON /MYPROG/ FILEVARS(10) OPENSEQ /tmp/file.txt to FILEVARS(1) ELSE ... This operation results abnormal termination with fault type error 11. Fault occurred at address 1c (which is the OPENSEQ command.). If the file size is less than 2147483647 bytes (2Gb), it works. Opening the same file using a scalar file variable always work irrespective of the file size. OPENSEQ /tmp/file.txt TO FV.FILE ELSE ... Any reason why the first method failing for +2Gb files? Any workarounds? Universe: 10.2.7 AIX: 5.3 Thanks Rajesh Menon ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
What happens wif you open to regular variable then pass it over to the array: OPENSEQ TO FVAR FILEVARS(1) = FVAR ? Regards, Marc -Mensaje original- De: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] En nombre de Rajesh Menon Enviado el: lunes, 17 de mayo de 2010 16:12 Para: U2 Users List Asunto: Re: [U2] OPENSEQ and Abnormal termination of UV Yes file system is setup to support +2Gb files. As I mentioned I can open the file using a scalar file variable. Problem happening only with the combination of +2Gb and using array variable. Thanks, Rajesh -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble Sent: Monday, May 17, 2010 12:00 PM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] OPENSEQ and Abnormal termination of UV You may want to check with your Systems Administrator to be sure your file system is setup to support files larger than 2gig - Original Message - From: u2-users-boun...@listserver.u2ug.org u2-users-boun...@listserver.u2ug.org To: u2-users@listserver.u2ug.org u2-users@listserver.u2ug.org Sent: Mon May 17 14:55:30 2010 Subject: [U2] OPENSEQ and Abnormal termination of UV Does anyone knows what is happening here: I am trying to open a text file (over 4Gb) using OPENSEQ and storing the file variable into a array as follows: COMMON /MYPROG/ FILEVARS(10) OPENSEQ /tmp/file.txt to FILEVARS(1) ELSE ... This operation results abnormal termination with fault type error 11. Fault occurred at address 1c (which is the OPENSEQ command.). If the file size is less than 2147483647 bytes (2Gb), it works. Opening the same file using a scalar file variable always work irrespective of the file size. OPENSEQ /tmp/file.txt TO FV.FILE ELSE ... Any reason why the first method failing for +2Gb files? Any workarounds? Universe: 10.2.7 AIX: 5.3 Thanks Rajesh Menon ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
I'd call this one a bug. I just tried the following on 10.2.7 on RHEL5... OPENSEQ '/data/trax/CLM.IDX/OVER.30' TO SEQ.TEST ELSE ABORT STATUS FS FROM SEQ.TEST ELSE ABORT CLOSESEQ SEQ.TEST CRT 'FILE SIZE = ': FS6 I get... FILE SIZE = 10146506752 But if I run... DIM FVARS(10) OPENSEQ '/data/trax/CLM.IDX/OVER.30' TO FVARS(1) ELSE ABORT STATUS FS FROM FVARS(1) ELSE ABORT CLOSESEQ FVARS(1) CRT 'FILE SIZE = ': FS6 I get... Abnormal termination of UniVerse. Fault type is 11. Layer type is BASIC run machine. Fault occurred in BASIC program PTEST at address 5a. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Marc A Hilbert Sent: Monday, May 17, 2010 3:41 PM To: 'U2 Users List' Subject: Re: [U2] OPENSEQ and Abnormal termination of UV What happens wif you open to regular variable then pass it over to the array: OPENSEQ TO FVAR FILEVARS(1) = FVAR ? Regards, Marc -Mensaje original- De: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] En nombre de Rajesh Menon Enviado el: lunes, 17 de mayo de 2010 16:12 Para: U2 Users List Asunto: Re: [U2] OPENSEQ and Abnormal termination of UV Yes file system is setup to support +2Gb files. As I mentioned I can open the file using a scalar file variable. Problem happening only with the combination of +2Gb and using array variable. Thanks, Rajesh -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble Sent: Monday, May 17, 2010 12:00 PM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] OPENSEQ and Abnormal termination of UV You may want to check with your Systems Administrator to be sure your file system is setup to support files larger than 2gig - Original Message - From: u2-users-boun...@listserver.u2ug.org u2-users-boun...@listserver.u2ug.org To: u2-users@listserver.u2ug.org u2-users@listserver.u2ug.org Sent: Mon May 17 14:55:30 2010 Subject: [U2] OPENSEQ and Abnormal termination of UV Does anyone knows what is happening here: I am trying to open a text file (over 4Gb) using OPENSEQ and storing the file variable into a array as follows: COMMON /MYPROG/ FILEVARS(10) OPENSEQ /tmp/file.txt to FILEVARS(1) ELSE ... This operation results abnormal termination with fault type error 11. Fault occurred at address 1c (which is the OPENSEQ command.). If the file size is less than 2147483647 bytes (2Gb), it works. Opening the same file using a scalar file variable always work irrespective of the file size. OPENSEQ /tmp/file.txt TO FV.FILE ELSE ... Any reason why the first method failing for +2Gb files? Any workarounds? Universe: 10.2.7 AIX: 5.3 Thanks Rajesh Menon ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
I think it's something along those lines, but I don't think it's trying to stick the entire contents of the file into a variable. What I think OPENSEQ is doing is keeping track of the position where the EOF mark is so it will know when the end of the file is reached. For a file greater than 2GB in size, this position is an integer that takes more than 32 bits to store. UV, being a 32-bit application, is not going to be able to handle it. The maximum positive integer value a 32-bit application can reference is 2147483647. One workaround might be to use EXECUTE to shell out to an OS-level command or script that parses the file out into multiple smaller temp files that can then be accessed by UV. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jpb-u2ug Sent: Monday, May 17, 2010 12:33 PM To: 'U2 Users List' Subject: Re: [U2] OPENSEQ and Abnormal termination of UV Let me see, can it be because you are trying to cram over 4 GB of data into a single cell. Unlike the OPEN statement that just puts the file variable into a variable, the OPENSEQ opens the whole file to the variable. Jerry Banker -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Rajesh Menon Sent: Monday, May 17, 2010 1:56 PM To: u2-users@listserver.u2ug.org Subject: [U2] OPENSEQ and Abnormal termination of UV Does anyone knows what is happening here: I am trying to open a text file (over 4Gb) using OPENSEQ and storing the file variable into a array as follows: COMMON /MYPROG/ FILEVARS(10) OPENSEQ /tmp/file.txt to FILEVARS(1) ELSE ... This operation results abnormal termination with fault type error 11. Fault occurred at address 1c (which is the OPENSEQ command.). If the file size is less than 2147483647 bytes (2Gb), it works. Opening the same file using a scalar file variable always work irrespective of the file size. OPENSEQ /tmp/file.txt TO FV.FILE ELSE ... Any reason why the first method failing for +2Gb files? Any workarounds? Universe: 10.2.7 AIX: 5.3 Thanks Rajesh Menon ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] OPENSEQ and Abnormal termination of UV
Normally when I run into a statement that doesn't like mv or dimmed arrays I just assign before or after Like: SEARCH.FOR = ABC1,J LOCATE SEARCH.FOR IN DEF SETTING bla bla bla or in this case OPENSEQ '/data/trax/CLM.IDX/OVER.30' TO SEQ.TEST ELSE ABORT FVARS(1) = SEQ.TEST I haven't tested this to see if it works - I have my own dragons to slay right now :-) Perry Taylor perry.tay...@zirmed.com wrote: = I'd call this one a bug. I just tried the following on 10.2.7 on RHEL5... OPENSEQ '/data/trax/CLM.IDX/OVER.30' TO SEQ.TEST ELSE ABORT STATUS FS FROM SEQ.TEST ELSE ABORT CLOSESEQ SEQ.TEST CRT 'FILE SIZE = ': FS6 I get... FILE SIZE = 10146506752 But if I run... DIM FVARS(10) OPENSEQ '/data/trax/CLM.IDX/OVER.30' TO FVARS(1) ELSE ABORT STATUS FS FROM FVARS(1) ELSE ABORT CLOSESEQ FVARS(1) CRT 'FILE SIZE = ': FS6 I get... Abnormal termination of UniVerse. Fault type is 11. Layer type is BASIC run machine. Fault occurred in BASIC program PTEST at address 5a. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Marc A Hilbert Sent: Monday, May 17, 2010 3:41 PM To: 'U2 Users List' Subject: Re: [U2] OPENSEQ and Abnormal termination of UV What happens wif you open to regular variable then pass it over to the array: OPENSEQ TO FVAR FILEVARS(1) = FVAR ? Regards, Marc -Mensaje original- De: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] En nombre de Rajesh Menon Enviado el: lunes, 17 de mayo de 2010 16:12 Para: U2 Users List Asunto: Re: [U2] OPENSEQ and Abnormal termination of UV Yes file system is setup to support +2Gb files. As I mentioned I can open the file using a scalar file variable. Problem happening only with the combination of +2Gb and using array variable. Thanks, Rajesh -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dan Goble Sent: Monday, May 17, 2010 12:00 PM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] OPENSEQ and Abnormal termination of UV You may want to check with your Systems Administrator to be sure your file system is setup to support files larger than 2gig - Original Message - From: u2-users-boun...@listserver.u2ug.org u2-users-boun...@listserver.u2ug.org To: u2-users@listserver.u2ug.org u2-users@listserver.u2ug.org Sent: Mon May 17 14:55:30 2010 Subject: [U2] OPENSEQ and Abnormal termination of UV Does anyone knows what is happening here: I am trying to open a text file (over 4Gb) using OPENSEQ and storing the file variable into a array as follows: COMMON /MYPROG/ FILEVARS(10) OPENSEQ /tmp/file.txt to FILEVARS(1) ELSE ... This operation results abnormal termination with fault type error 11. Fault occurred at address 1c (which is the OPENSEQ command.). If the file size is less than 2147483647 bytes (2Gb), it works. Opening the same file using a scalar file variable always work irrespective of the file size. OPENSEQ /tmp/file.txt TO FV.FILE ELSE ... Any reason why the first method failing for +2Gb files? Any workarounds? Universe: 10.2.7 AIX: 5.3 Thanks Rajesh Menon ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
RE: [U2] openseq question
Thank you all. It is working now with the VOC pointer. It is much simpler now that I don't care what account I'm in. One final question. I have downloaded many of the pdfs ( UniBasic command ref., Using unidata, SB+ Solutions, ...) from the IBM site but where is this documented? Are there any books ( online or otherwise ) that a novice to unidata programming could refer to in cases like this? What I've looked at so far is more like a quick reference and doesn't really dive into detail. For example the difference handling absolute-path and VOC pointer with using the full path vs. path,rec-id approach. Thanks again, Jeff On Wed, 2006-01-04 at 19:04 -0700, Kevin King wrote: Jeff, if the VOC entry is MFG.DATA.IPS.TMP then the OPEN is: OPEN MFG.DATA.IPS.TMP, MTR.REC TO ... Not the concatenated thing you had in your post. -K --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Gaaa! no...most of the files I've uploaded were measly little files. Tiny, little itty bitty files. Like specs on the wall small. Mostly forecast files where you just have 12 three to four char qty's for a couple thousand parts. And you gotta realize that people get used to their graphs. In the corporate world people like warm and fuzziesstuff that costs a lot of system resources and adds no value but makes them feel good. So they get to see that the upload is going to take ten minutes so off to the break room they go. And yesI can guarantee that the files will be small because the company doesn't exist any more ;) Warm and fuzzies. I had a morning report that I spent probably close to 1000 hours on, that would break out projections for the end of the month and compare it to budget and do crazy stuff like show how much more warehouses had to ship, or how much less to make the projection for the EOM. Like, as if seeing the shortage at the end of the month would make the customers order more Butit made the guy setting in the top floor at the big desk feel good. Total waste of time, but he felt good. Company is gone now, but he felt good. * == SCREEN.GRAPH: DONE.PCT=INT(((RECORDS.READ*100)/SELECTED)+.5) SMSG=DONE.PCT:' Percent Done, ':RECORDS.READ:' Records Read out of ':SELECTED:' selected' CC=40-(INT(LEN(SMSG)/2)) CRT L(10):C(CC):SMSG:EOL DONE.CNTR=INT((DONE.PCT*60+50)/100) CRT L(12):C(10):STR(LX,DONE.CNTR) CRT L(13):C(10):STR(LX,DONE.CNTR) SMSG='Projected Finish Time : ':OCONVTIME()-WAS)/DONE.PCT)*100)+WAS,'MTHS') CC=40-(INT(LEN(SMSG)/2)) CRT L(15):C(CC):SMSG:EOL SMSG='Current Time : ':OCONV(TIME(),'MTHS') CC=40-(INT(LEN(SMSG)/2)) CRT L(16):C(CC):SMSG:EOL CRT L(20):C(1): RETURN * = ACTUAL.FINISH.TIME: SMSG='Actual Finish Time : ':OCONV(TIME(),'MTHS') CC=40-(INT(LEN(SMSG)/2)) CRT L(17):C(CC):SMSG:EOL CRT L(20):C(1): RETURN * == Allen E. Elwood www.tortillafc.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Timothy Snyder Sent: Wednesday, January 04, 2006 19:12 To: u2-users@listserver.u2ug.org Subject: RE: [U2] openseq question Allen E. Elwood wrote on 01/04/2006 01:29:47 PM: I've always found it helpful to open the file/record in 'regular' mode first to find out if the directory entry worked or possibly to write a null record if it didn't. So, if the O/S-level file is multi-megabytes, you're reading the whole thing into memory? That could cause problems with shared memory and will certainly create a burden on the system. It also kind of defeats the purpose of using a sequential file, since you're reading the whole thing in, then opening it again and reading through the entire file a second time with READSEQ. Since you've incurred the memory and performance hit to pull the whole thing into a variable, you might as well waltz through that variable to extract the lines an attribute at a time with REMOVE or READNEXT. If you're following this practice only on small files, and only infrequently, it's probably OK, but how can you guarantee that will always be the case? Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Jeff, AFAIR OpenSeq on UniData looks for either a path name, or if you specify an item id it looks for an item in a directory file (not a path). So you would need to either A) OPENSEQ /tmp/ : MTR.REC TO F.MTR.ROW.FILE ... Or B) create a file pointer to /tmp (e.g. named TMP) and then OPENSEQ TMP,MTR.REC TO F.MTR.ROW.FILE ... Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Powell Sent: 04 January 2006 14:31 To: u2 users group Subject: [U2] openseq question Happy New Year. I am having trouble with the openseq function in UniData. We are operation in Pick mode. Openseq can't find the specified file at path,filename. Is there an assumed prefix? Here is the code frag that is failing. MTR.FILE.PATH='/tmp' OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE EXECUTE '!touch ':MTR.FILE.PATH:/:MTR.REC OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE CALL SB.DISP(3,TROUBLE OPENING :MTR.FILE.PATH:/:MTR.REC: [E:STATUS():]) GO PGM.EXIT END END Thanks, Jeff --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Is it a permissions problem? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Powell Sent: Wednesday, January 04, 2006 8:31 AM To: u2 users group Subject: [U2] openseq question Happy New Year. I am having trouble with the openseq function in UniData. We are operation in Pick mode. Openseq can't find the specified file at path,filename. Is there an assumed prefix? Here is the code frag that is failing. MTR.FILE.PATH='/tmp' OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE EXECUTE '!touch ':MTR.FILE.PATH:/:MTR.REC OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE CALL SB.DISP(3,TROUBLE OPENING :MTR.FILE.PATH:/:MTR.REC: [E:STATUS():]) GO PGM.EXIT END END Thanks, Jeff --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Jeff, I think Openseq looks either for a fully specified path to the file as in : OPENSEQ /tmp/recordname TO F.MTR.ROW ELSE or it understands the filename, recordname construct but looks for the filename in the VOC, as in OPENSEQ TMPFIL, recordname to F.MTR.ROW ELSE... where TMPFIL is a DIR type VOC entry pointing to /tmp but it can't cope with your construct which is effectively OPENSEQ '/tmp', recordname hth Piers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Powell Sent: 04 January 2006 14:31 To: u2 users group Subject: [U2] openseq question Happy New Year. I am having trouble with the openseq function in UniData. We are operation in Pick mode. Openseq can't find the specified file at path,filename. Is there an assumed prefix? Here is the code frag that is failing. MTR.FILE.PATH='/tmp' OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE EXECUTE '!touch ':MTR.FILE.PATH:/:MTR.REC OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE CALL SB.DISP(3,TROUBLE OPENING :MTR.FILE.PATH:/:MTR.REC: [E:STATUS():]) GO PGM.EXIT END END Thanks, Jeff --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
No. /tmp is an absolute path. On Wed, 2006-01-04 at 09:47 -0500, Koser, Mike wrote: Jeff Is '/tmp' in the VOC? Mike -Original Message- From: Jeff Powell [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 04, 2006 9:31 AM To: u2 users group Subject: [U2] openseq question Happy New Year. I am having trouble with the openseq function in UniData. We are operation in Pick mode. Openseq can't find the specified file at path,filename. Is there an assumed prefix? Here is the code frag that is failing. MTR.FILE.PATH='/tmp' OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE EXECUTE '!touch ':MTR.FILE.PATH:/:MTR.REC OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE CALL SB.DISP(3,TROUBLE OPENING :MTR.FILE.PATH:/:MTR.REC: [E:STATUS():]) GO PGM.EXIT END END Thanks, Jeff --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ __ This e-mail has been scanned by MCI Managed Email Content Service, using Skeptic(tm) technology powered by MessageLabs. For more information on MCI's Managed Email Content Service, visit http://www.mci.com. __ __ This e-mail has been scanned by MCI Managed Email Content Service, using Skeptic(tm) technology powered by MessageLabs. For more information on MCI's Managed Email Content Service, visit http://www.mci.com. __ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ Jeff Powell IT Manager Industrial Piping Specialists 606 N. 145th Ave. E. Tulsa, OK 74166 (918) 270-6311 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Your syntax is a little off. When you use the seq.file.name, record.id syntax then seq.file.name has to be a dir type file. You will have to either create a voc entry for /tmp, eg.: TMP.DIR 001 DIR 002 /tmp 003 D_VOC And then you should be able to: MTR.FILE.PATH = TMP.DIR Or you can OPENSEQ MTR.FILE.PATH:/MTR.REC Hth Colin Alfke Calgary Canada -Original Message- From: Jeff Powell Happy New Year. I am having trouble with the openseq function in UniData. We are operation in Pick mode. Openseq can't find the specified file at path,filename. Is there an assumed prefix? Here is the code frag that is failing. MTR.FILE.PATH='/tmp' OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE EXECUTE '!touch ':MTR.FILE.PATH:/:MTR.REC OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE CALL SB.DISP(3,TROUBLE OPENING :MTR.FILE.PATH:/:MTR.REC: [E:STATUS():]) GO PGM.EXIT END END Thanks, Jeff --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
You need to have MTR.FILE.PATH open as a file handle, first. You can do one of the following: MTR.FILE.PATH='/tmp' OPEN MTR.FILE.PATH TO MTR.FILE ELSE STOP MTR.REC = 'RECID' OPENSEQ MTR.FILE,MTR.REC TO F.MTR.ROW.FILE ELSE [what you already have] END Or open the full path directly: MTR.FILE.PATH='/tmp' MTR.REC='RECID' OPENSEQ MTR.FILE.PATH:'/':MTR.REC TO F.MTR.ROW.FILE ELSE [what you already have] END BobW -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Powell Sent: Wednesday, January 04, 2006 6:31 AM To: u2 users group Subject: [U2] openseq question Happy New Year. I am having trouble with the openseq function in UniData. We are operation in Pick mode. Openseq can't find the specified file at path,filename. Is there an assumed prefix? Here is the code frag that is failing. MTR.FILE.PATH='/tmp' OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE EXECUTE '!touch ':MTR.FILE.PATH:/:MTR.REC OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE CALL SB.DISP(3,TROUBLE OPENING :MTR.FILE.PATH:/:MTR.REC: [E:STATUS():]) GO PGM.EXIT END END Thanks, Jeff --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
I've actually had problems with various versions of Unidata and CLOSESEQ releasing the file when opening a full path. Opening under a VOC DIR-pointer has never exhibited that problem, so I'd recommend the VOC pointer approach over using a full path. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Several years ago I created a little utility to open sequential files as needed. It's pretty robust; hasn't given me much trouble over the years. Like Kevin, I've had problems with the full path version of openseq, so my utility converts full path mode to VOC pointer mode and creates the VOC pointer if it doesn't already exist. I'll include it below and attach it in text form. Dana Baron System Manager Smugglers' Notch Resort SUBROUTINE OPEN_UNIX_FILE (UNIX.FN, MODE, UNIX.FILE, ERR.CODE) !** ! SYSTEM: AHS ! MODULE: UTILITY ! PROGRAM:OPEN_UNIX_FILE ! ! DESCRIPTION:This subroutine opens a sequential file. Sequential ! files can be used to export Unidata data to UNIX. ! ! Notes: The parameters passed to this routine are: ! ! UNIX.FN - the full file name of the file to open. ! MODE - expects the following choices: ! C - create a new file ! U - update existing file (error message if not there) ! UC- update the file if it exists, create a new file if ! it doesn't exist. ! UNIX.FILE - the file reference num returned to calling program ! ERR.CODE - Error code to indicate results as follows: ! 0 = No error. Everthing is OK. ! 1 = (Fatal) Can't open the VOC item for the directory ! 2 = (Info) VOC item for directory already defined ! 3 = (Info) In C mode, file exists so renamed ! 4 = (Warning) In U mode, file does not exist ! 5 = (Fatal, calling program bug) Invalid mode parameter ! !** ! MODIFICATION HISTORY ! ! EDIT DATE WHO REASON/DESCRIPTION ! ! 07/12/96 GDB Created ! ! 11/14/97 GDB Added UC mode to update file if it exists, create ! the file if it doesn't exist. ! ! 02/15/01 GDB Copied OPEN_VMS_FILE to OPEN_UNIX_FILE and modified ! to work in Unix as part of conversion from VMS to Unix. !** TRUE = 1 FALSE = 0 ERR.CODE = 0 OPEN ,VOC TO VOC.FILE ELSE PRINT CANT OPEN VOC!!! ERR.CODE = 1 ABORT END !DEBUG NUM.SLASH = DCOUNT(UNIX.FN, /) UNIX.DIR = UNIX.ID = FIELD(UNIX.FN,/,NUM.SLASH) FOR II = 2 TO NUM.SLASH - 1 UNIX.DIR = UNIX.DIR : / : FIELD(UNIX.FN,/,II) NEXT II VOC.ITEM = DIR:@AM:UNIX.DIR READ TEST.ITEM FROM VOC.FILE , UNIX.DIR THEN IF (TEST.ITEM2) = UNIX.DIR THEN NULL END ELSE PRINT VOC ITEM ':UNIX.DIR:' DEFINED IN VOC AS : PRINT '' : TEST.ITEM : '' ERR.CODE = 2 END END ELSE WRITE VOC.ITEM ON VOC.FILE , UNIX.DIR END BEGIN CASE CASE MODE = C PASS = 1 RENAME = FALSE DONE = 0 NEW.UNIX.ID = UNIX.ID LOOP UNTIL DONE DO OPENSEQ UNIX.DIR, NEW.UNIX.ID TO UNIX.FILE THEN PRINT FILE ALREADY EXISTS...RENAMING NEW.UNIX.ID = UNIX.ID : _ : PASS RENAME = TRUE PASS = PASS + 1 ERR.CODE = 3 END ELSE DONE = 1 END REPEAT IF RENAME = TRUE THEN PRINT FILE RENAMED TO : NEW.UNIX.ID END CASE MODE = U DONE = 0 OPENSEQ UNIX.DIR, UNIX.ID TO UNIX.FILE ELSE PRINT FILE DOES NOT EXIST ERR.CODE = 4 END CASE MODE = UC DONE = 0 OPENSEQ UNIX.DIR, UNIX.ID TO UNIX.FILE ELSE ! File doesn't exist. A new file is created END CASE -1 PRINT Function called with a bad Mode parameter. ERR.CODE = 5 END CASE RETURN SUBROUTINE OPEN_UNIX_FILE (UNIX.FN, MODE, UNIX.FILE, ERR.CODE) !** ! SYSTEM: AHS ! MODULE: UTILITY ! PROGRAM:OPEN_UNIX_FILE ! ! DESCRIPTION:This subroutine opens a sequential file. Sequential ! files can be used to export Unidata data to
RE: [U2] openseq question
I've always found it helpful to open the file/record in 'regular' mode first to find out if the directory entry worked or possibly to write a null record if it didn't. I like to have a graph display, and this way I can tell how many 'records' (or AMCs in this case) I'm going to be processing so I can display the forecasted time of completion. READ TRANSFER.REC FROM TRF, 'AKSS.FCST' ELSE SS='Attention, this function was unable to retrieve the Forecast file ' SS:='from the net - Now Aborting Function!;b;e;a;c;h' CALL SCREEN.MSG(SS) GOTO Programmed_Abort END OPENSEQ TRANSFER, AKSS.FCST READONLY TO TRF.SEQ ELSE SS='This function was unable to access a record that was just written to ' SS='the TRANSFER directory. As a result, it cannot continue ' SS='- now aborting!;b;c;h' CALL SCREEN.MSG(SS) GOTO Programmed_Abort END NBR.OF.ATTRS=DCOUNT(TRANSFER.REC,@AM) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Powell Sent: Wednesday, January 04, 2006 06:31 To: u2 users group Subject: [U2] openseq question Happy New Year. I am having trouble with the openseq function in UniData. We are operation in Pick mode. Openseq can't find the specified file at path,filename. Is there an assumed prefix? Here is the code frag that is failing. MTR.FILE.PATH='/tmp' OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE EXECUTE '!touch ':MTR.FILE.PATH:/:MTR.REC OPENSEQ MTR.FILE.PATH, MTR.REC TO F.MTR.ROW.FILE ELSE CALL SB.DISP(3,TROUBLE OPENING :MTR.FILE.PATH:/:MTR.REC: [E:STATUS():]) GO PGM.EXIT END END Thanks, Jeff --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Hi Kevin Do you recall which OS this was on? I don't believe I've run into this problem but I'm currently using Windows (2000 and 2003) but I've also been on RS6000 and DG/UX. All of this is with UV. Thanks. BobW -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin King Sent: Wednesday, January 04, 2006 9:36 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] openseq question I've actually had problems with various versions of Unidata and CLOSESEQ releasing the file when opening a full path. Opening under a VOC DIR-pointer has never exhibited that problem, so I'd recommend the VOC pointer approach over using a full path. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Thank you for all your helpful suggestions. I am now looking at creating a VOC pointer as Kevin suggests below. Actually I'll need to create two pointers one for the TEST account and another for the LIVE account. I had originally tried the PATH:FILE syntax before I found out that the file needed to exist before it could be opened. So I went to the other syntax hoping to resolve the non-existant file issue. Here is the current function without the VOC pointer. GOSUB GET.MTR.COUNTER MTR.REC=MTR:OCONV(DATE(),D2/):OCONV(MTR.CTR,MR%4):.ROW CONVERT / TO IN MTR.REC MTR.FILE.PATH='/tmp/MFG.DATA.IPS' IF @PATH = /ud/TEST THEN MTR.FILE.PATH=MTR.FILE.PATH:'.TEST' END MTR.FILE.PATH=MTR.FILE.PATH:'/tmp/' OPENSEQ MTR.FILE.PATH:MTR.REC TO F.MTR.ROW.FILE ELSE EXECUTE '!touch ':MTR.FILE.PATH:MTR.REC OPENSEQ MTR.FILE.PATH:MTR.REC TO F.MTR.ROW.FILE ELSE CALL SB.DISP(3,TROUBLE OPENING :MTR.FILE.PATH:MTR.REC: [E:STATUS():]) GO PGM.EXIT END END WRITESEQ LASTREC APPEND ON F.MTR.ROW.FILE ELSE CALL SB.DISP(3,TROUBLE WRITING TO :MTR.FILE.PATH:MTR.REC [E:STATUS():]) GO PGM.EXIT END CLOSESEQ F.MTR.ROW.FILE RETURN Thanks again. On Wed, 2006-01-04 at 10:35 -0700, Kevin King wrote: I've actually had problems with various versions of Unidata and CLOSESEQ releasing the file when opening a full path. Opening under a VOC DIR-pointer has never exhibited that problem, so I'd recommend the VOC pointer approach over using a full path. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Do you recall which OS this was on? I don't believe I've run into this problem but I'm currently using Windows (2000 and 2003) but I've also been on RS6000 and DG/UX. All of this is with UV. Unidata on Windows, as I recall. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Jeff; I use a VOC pointer for exactly this reason. It doesn't matter which account/where the directory is - I just need the VOC pointer that points to it. It makes it really easy to transfer from TEST to LIVE. Also, as Tim pointed out, you don't need the file to exist to open it. In fact, I have a bunch of export routines that throw an error if the file exists when it opens it. Hth Colin Alfke Calgary Canada -Original Message- From: Jeff Powell Thank you for all your helpful suggestions. I am now looking at creating a VOC pointer as Kevin suggests below. Actually I'll need to create two pointers one for the TEST account and another for the LIVE account. I had originally tried the PATH:FILE syntax before I found out that the file needed to exist before it could be opened. So I went to the other syntax hoping to resolve the non-existant file issue. Here is the current function without the VOC pointer. GOSUB GET.MTR.COUNTER MTR.REC=MTR:OCONV(DATE(),D2/):OCONV(MTR.CTR,MR%4):.ROW CONVERT / TO IN MTR.REC MTR.FILE.PATH='/tmp/MFG.DATA.IPS' IF @PATH = /ud/TEST THEN MTR.FILE.PATH=MTR.FILE.PATH:'.TEST' END MTR.FILE.PATH=MTR.FILE.PATH:'/tmp/' OPENSEQ MTR.FILE.PATH:MTR.REC TO F.MTR.ROW.FILE ELSE EXECUTE '!touch ':MTR.FILE.PATH:MTR.REC OPENSEQ MTR.FILE.PATH:MTR.REC TO F.MTR.ROW.FILE ELSE CALL SB.DISP(3,TROUBLE OPENING :MTR.FILE.PATH:MTR.REC: [E:STATUS():]) GO PGM.EXIT END END WRITESEQ LASTREC APPEND ON F.MTR.ROW.FILE ELSE CALL SB.DISP(3,TROUBLE WRITING TO :MTR.FILE.PATH:MTR.REC [E:STATUS():]) GO PGM.EXIT END CLOSESEQ F.MTR.ROW.FILE RETURN Thanks again. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Unidata on Unix has this issue, too (at least the DEC Tru64 flavor) -- it holds onto the file lock after CLOSESEQ of a file OPENSEQed with the Unix path. Don't know if it's been fixed in newer UD releases, but not likely a priority since OPENSEQ of a VOC pointer doesn't have the problem. [EMAIL PROTECTED] 01/04/06 2:53 PM Do you recall which OS this was on? I don't believe I've run into this problem but I'm currently using Windows (2000 and 2003) but I've also been on RS6000 and DG/UX. All of this is with UV. Unidata on Windows, as I recall. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ - This e-mail and any attachments may contain CONFIDENTIAL information, including PROTECTED HEALTH INFORMATION. If you are not the intended recipient, any use or disclosure of this information is STRICTLY PROHIBITED; you are requested to delete this e-mail and any attachments, notify the sender immediately, and notify the LabCorp Privacy Officer at [EMAIL PROTECTED] or call (877) 23-HIPAA / (877) 234-4722. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Actually I'll need to create two pointers one for the TEST account and another for the LIVE account. This is one of the great features of the VOC pointer; the LIVE account can point to the directory it needs and the TEST account can point to the directory it needs and the program doesn't have to be none the wiser. Of course, if the program needs to access both at the same time that's a whole different issue... -K --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Thanks again to everyone for all their help. I'm almost there. I want to use the VOC pointer so I created the pointers in my Live and Test VOC files, logged out and back in to ensure I was reading VOC but I'm still not meeting with any success. When I attempt to reference the pointer I get a Unintialized Variable warning during compile and 0 (zero) assumed error during execution. The path looks like 0/MTR01040600nn.ROW LIST VOC F1 F2 F3 VERTICAL MFG.DATA.IPS.TMP 16:27:26 Jan 04 2006 1 VOC MFG.DATA.IPS.TMP F1DIR F2/tmp/MFG.DATA.IPS.TEST/tmp F3D_VOC GOSUB GET.MTR.COUNTER MTR.REC=MTR:OCONV(DATE(),D2/):OCONV(MTR.CTR,MR%4):.ROW CONVERT / TO IN MTR.REC * -- The following line fails to compile MTR.FILE.PATH=MFG.DATA.IPS.TMP * -- Tim suggested the following WEOFSEQ approach to create a new file. I'll remove the CRT statements after debugging is over. OPENSEQ MTR.FILE.PATH:/:MTR.REC TO F.MTR.ROW.FILE THEN CRT 'Existing file' END ELSE CRT 'Creating new file' END WEOFSEQ F.MTR.ROW.FILE WRITESEQ LASTREC APPEND ON F.MTR.ROW.FILE ELSE CALL SB.DISP(3,TROUBLE WRITING TO :MTR.FILE.PATH:/:MTR.REC [E:STATUS():]) GO PGM.EXIT END CLOSESEQ F.MTR.ROW.FILE RETURN On Wed, 2006-01-04 at 14:38 -0700, Kevin King wrote: Actually I'll need to create two pointers one for the TEST account and another for the LIVE account. This is one of the great features of the VOC pointer; the LIVE account can point to the directory it needs and the TEST account can point to the directory it needs and the program doesn't have to be none the wiser. Of course, if the program needs to access both at the same time that's a whole different issue... -K --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Jeff, if the VOC entry is MFG.DATA.IPS.TMP then the OPEN is: OPEN MFG.DATA.IPS.TMP, MTR.REC TO ... Not the concatenated thing you had in your post. -K --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Jeff Powell wrote: Thanks again to everyone for all their help. I'm almost there. I want to use the VOC pointer so I created the pointers in my Live and Test VOC files, logged out and back in to ensure I was reading VOC but I'm still not meeting with any success. When I attempt to reference the pointer I get a Unintialized Variable warning during compile and 0 (zero) assumed error during execution. The path looks like 0/MTR01040600nn.ROW LIST VOC F1 F2 F3 VERTICAL MFG.DATA.IPS.TMP 16:27:26 Jan 04 2006 1 VOC MFG.DATA.IPS.TMP F1DIR F2/tmp/MFG.DATA.IPS.TEST/tmp F3D_VOC GOSUB GET.MTR.COUNTER MTR.REC=MTR:OCONV(DATE(),D2/):OCONV(MTR.CTR,MR%4):.ROW CONVERT / TO IN MTR.REC * -- The following line fails to compile MTR.FILE.PATH=MFG.DATA.IPS.TMP Jeff, You have set up MFG.DATA.IPS.TMP as a VOC pointer, but if you reference it in BASIC without quotes, the compiler thinks it is an unassigned variable. So, step one, wrap the name of your VOC pointer in quotes. However, you've said you want to use VOC pointers instead of paths, so instead of appending a / and the record name, you want to OPENSEQ the VOC name , the record name. So, step two, use the VOC,record syntax, not the path syntax: OPENSEQ MFG.DATA.IPS.TMP,MTR.REC TO MTR.REC.VBLE ELSE * remember in UniData, OPENSEQ creates automatically WEOFSEQ MTR.REC.VBLE END Other points: 1) It really isn't a great idea to go creating application specific subdirectories in /tmp. Fill /tmp up with junk and the system will crash sooner or later. 2) If you need the path of an opened file variable use FILEINFO(). Cheers, Ken --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Allen E. Elwood wrote on 01/04/2006 01:29:47 PM: I've always found it helpful to open the file/record in 'regular' mode first to find out if the directory entry worked or possibly to write a null record if it didn't. So, if the O/S-level file is multi-megabytes, you're reading the whole thing into memory? That could cause problems with shared memory and will certainly create a burden on the system. It also kind of defeats the purpose of using a sequential file, since you're reading the whole thing in, then opening it again and reading through the entire file a second time with READSEQ. Since you've incurred the memory and performance hit to pull the whole thing into a variable, you might as well waltz through that variable to extract the lines an attribute at a time with REMOVE or READNEXT. If you're following this practice only on small files, and only infrequently, it's probably OK, but how can you guarantee that will always be the case? Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] openseq question
Further to this, you could also use the !GET.PATHNAME subroutine to get the path and filename. A quick way to check rather than the expense of a DB level OPEN. Regards --- ** _/ ** David Logan *** _/ *** ITO Delivery Specialist - Database *_/* Hewlett-Packard Australia Ltd _/_/_/ _/_/_/ E-Mail: [EMAIL PROTECTED] _/ _/ _/ _/ Desk: +618 8408 4273 _/ _/ _/_/_/ Mobile: 0417 268 665 *_/ ** ** _/ Postal: 148 Frome Street, _/ ** Adelaide SA 5001 Australia invent --- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Snyder Sent: Thursday, 5 January 2006 1:42 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] openseq question Allen E. Elwood wrote on 01/04/2006 01:29:47 PM: I've always found it helpful to open the file/record in 'regular' mode first to find out if the directory entry worked or possibly to write a null record if it didn't. So, if the O/S-level file is multi-megabytes, you're reading the whole thing into memory? That could cause problems with shared memory and will certainly create a burden on the system. It also kind of defeats the purpose of using a sequential file, since you're reading the whole thing in, then opening it again and reading through the entire file a second time with READSEQ. Since you've incurred the memory and performance hit to pull the whole thing into a variable, you might as well waltz through that variable to extract the lines an attribute at a time with REMOVE or READNEXT. If you're following this practice only on small files, and only infrequently, it's probably OK, but how can you guarantee that will always be the case? Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OPENSEQ filesize limit?
I would think that you have actually gone over the file size limit of Linux ... tail head may not REALLY be working (accurately). I actually thought the limit was 2Gb (which is why the need for partitioned files in the first place). Happy to be wrong (not an active UD user), but had a similar problem once when I copied a BIG file from a windows box to Linux across a Samba Share Ross Ferris Stamina Software Visage Better by Design! -Original Message- From: [EMAIL PROTECTED] [mailto:owner-u2- [EMAIL PROTECTED] On Behalf Of Eugene Perry Sent: Friday, 19 August 2005 1:05 PM To: u2-users@listserver.u2ug.org Subject: [U2] OPENSEQ filesize limit? Does OPENSEQ on Unidata have a limit to the size of the file that it will open? We are running Unidata 6.0.13 on linux and have a problem getting OPENSEQ to work with a file that is 2.4 gigs. We can use tail and head and have been able to copy the file etc. So it is not permissions. This is also an application that has worked for a long time so it is not that it is a new application. Any ideas? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OPENSEQ filesize limit?
Ross Ferris wrote: I would think that you have actually gone over the file size limit of Linux ... tail head may not REALLY be working (accurately). I actually thought the limit was 2Gb (which is why the need for partitioned files in the first place). Happy to be wrong (not an active UD user), but had a similar problem once when I copied a BIG file from a windows box to Linux across a Samba Share There was a 2GB file size limit on the ext2 filesystem with the 2.3 kernel, but I beleive that with the 2.4 kernel the max file size was upped to 2TB on ext2 and ext3 filesystems. -John -- John Hester System Network Administrator Momentum Group Inc. (949) 833-8886 x623 http://memosamples.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
