Re: [U2] SB+ editing question
Hi, Non-standard characters can often be added (possibly depending on editor, but it works here in SB Client), by holding down ALT and typing in the character code on the numeric pad. In the case of @VM, that would be alt+253. Adam -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of Lunt, Bruce Sent: 10 February 2012 00:58 To: u2-users@listserver.u2ug.org Subject: [U2] SB+ editing question Hi All I have a question about what key(s) to enter to insert a value mark when entering into a field in a screen. The field should probably be changed to multi-valued from single-valued but this is a generic field that is filled with data from anywhere in the record to be updated. So, when the multi-value field is displayed it shows a small 2 between each of the value positions. What is the keystroke to insert that 2? Thanks, Bruce ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users This electronic message contains information from CACI International Inc or subsidiary companies, which may be confidential, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify us immediately at postmas...@caci.co.uk Viruses: Although we have taken steps to ensure that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. CACI Limited. Registered in England Wales. Registration No. 1649776. CACI House, Avonmore Road, London, W14 8TS. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Including Code - A Best Practice?
Late to this, but I use includes with code in two situations: 1. As standard library pieces managed through a pre-compiler, usually for platform-dependent sections. For example, I have standard includes for getting command line arguments, reading and writing from ini files and so forth. The precompiler builds versions of the code for each supported platform (Universe, UniData, D3, QM etc) by pulling in the required blocks. I also make the same code available as subroutines (that have the same includes), but as I have a lot of utilities it's easier for me if each of them if relatively stand-alone and I can send them out without the need for any supporting code. 2. For self-initializing named common blocks. I use these extensively with web and GUI development, as it means I don't have to assume any specific start-up routine or entry point - I can just include the declaration and know it will be valid whatever piece of code is hit first. These are usually of the format: COMMON /SOMECOM/ prefix.PARAMS(SomeSize),prefix.INIT If prefix.INIT = @False Then .. go and initialize it, e.g. set params to empty, open files etc. prefix.INIT = @True End (remember that named common is initialized to zero i.e. @false not to empty). For example, a lot of my older green screen routines have a clipboard function and cursor handling. So I have a CLIPBOARD named common which needs to be set to empty to begin with, and a TERM named common that defines the terminal settings and keys, initially as a set of defaults then by reading overrides from an INI style record. They will be initialized by whatever routine uses either of them first, without having to call a start-up routine on login if they aren't going to be used. Brian -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Baker Hughes Sent: 07 February 2012 23:05 To: U2 Users List (u2-users@listserver.u2ug.org) Subject: [U2] Including Code - A Best Practice? A friendly discussion arose recently among some U2/MV Developers about whether to include code. If any of you have opinions about the positive aspects or negative aspects of this practice, please respond. Should it be adopted as a best practice, or rejected as special situation use only? Many shops probably include long sections of variable assignments, or perhaps globally opened files. This is pretty much accepted everywhere as a good practice. In question here is the insertion of actual code - business logic or screen I/O programs or code snippets. Maybe you know of methods to overcome some of the obvious downsides: unintended reassignment of local variables, difficulty in debugging, others. What are the positive upsides? Performance gains? What is the longest snippet you think should be included, if allowed? What advantage has included code over a CALL or a Function? Reuse. What else? Can the downsides be mitigated satisfactorily to justify the gains? Thanks so much. -Baker This communication, its contents and any file attachments transmitted with it are intended solely for the addressee(s) and may contain confidential proprietary information. Access by any other party without the express written permission of the sender is STRICTLY PROHIBITED. If you have received this communication in error you may not copy, distribute or use the contents, attachments or information in any way. Please destroy it and contact the sender. ___ 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] Including Code - A Best Practice?
I want to thank each contributor to this thread for the reasoned and professional responses. As always, very illuminating and instructive to be a part of this list. Thank you each. -Baker This communication, its contents and any file attachments transmitted with it are intended solely for the addressee(s) and may contain confidential proprietary information. Access by any other party without the express written permission of the sender is STRICTLY PROHIBITED. If you have received this communication in error you may not copy, distribute or use the contents, attachments or information in any way. Please destroy it and contact the sender. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] [mildly ot] - EDI and drop shipments
For those EDIers on the list. Do any of you process drop shipments using EDI for 850's? What method do you use? We were thinking : First N1 loop - N1 segment contains the BT and use the SAN (15 code) Second N1 loop - N1 segment contains the ST but use phone# for identification (12 code) N2 segment for Drop Ship Name N3 Segment(s) for Drop Ship Address (2 lines per N3 segment) - maximum 2 N3's N4 Segment for Drop Ship City, State, Zip and Country Currently we do not process drop shipments using EDI, and neither does this partner with any of Their other suppliers... George ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [mildly ot] - EDI and drop shipments
If you are using one ship to (drop ship) destination then what you suggest below is fine. We often have a 'BT' (bill to) N1, N3 and N4 followed by a 'ST' (ship to) N1, N3 and N4. Footnote: If you are going to have multiple destination in one PO, you will need to look into the SDQ segment. Barry Rogen Senior Programmer/Analyst PNY Technologies, Inc. (973) 560-5327 bro...@pny.com We are continually faced with great opportunities brilliantly disguised as insoluble problems. John W Gardner -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of George Gallen Sent: Friday, February 10, 2012 4:07 PM To: U2 Users Subject: [U2] [mildly ot] - EDI and drop shipments For those EDIers on the list. Do any of you process drop shipments using EDI for 850's? What method do you use? We were thinking : First N1 loop - N1 segment contains the BT and use the SAN (15 code) Second N1 loop - N1 segment contains the ST but use phone# for identification (12 code) N2 segment for Drop Ship Name N3 Segment(s) for Drop Ship Address (2 lines per N3 segment) - maximum 2 N3's N4 Segment for Drop Ship City, State, Zip and Country Currently we do not process drop shipments using EDI, and neither does this partner with any of Their other suppliers... George ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users NOT INTENDED AS A SUBSTITUTE FOR A WRITING NOTHING IN THIS E-MAIL, IN ANY E-MAIL THREAD OF WHICH IT MAY BE A PART, OR IN ANY ATTACHMENTS THERETO, SHALL CONSTITUTE A BINDING CONTRACT, OR ANY CONTRACTUAL OBLIGATION BY PNY, OR ANY INTENT TO ENTER INTO ANY BINDING OBLIGATIONS, NOTWITHSTANDING ANY ENACTMENT OF THE UNIFORM ELECTRONIC TRANSACTIONS ACT, THE FEDERAL E-SIGN ACT, OR ANY OTHER STATE OR FEDERAL LAW OF SIMILAR SUBSTANCE OR EFFECT. THIS EMAIL MESSAGE, ITS CONTENTS AND ATTACHMENTS ARE NOT INTENDED TO REPRESENT AN OFFER OR ACCEPTANCE OF AN OFFER TO ENTER INTO A CONTRACT. NOTHING IN THIS E-MAIL, IN ANY E-MAIL THREAD OF WHICH IT MAY BE A PART, OR IN ANY ATTACHMENTS THERETO SHALL ALTER THIS DISCLAIMER. This e-mail message from PNY Technologies, Inc. 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. 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] [mildly ot] - EDI and drop shipments
Didn't think about multiple destinationsI would hope that they separate their 850's on the drop ships So that each order is it's own destination. I don't think they want to get too complicated either, so I think we can agree on keeping it simple. Thanks George -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Barry Rogen Sent: Friday, February 10, 2012 4:21 PM To: U2 Users List Subject: Re: [U2] [mildly ot] - EDI and drop shipments If you are using one ship to (drop ship) destination then what you suggest below is fine. We often have a 'BT' (bill to) N1, N3 and N4 followed by a 'ST' (ship to) N1, N3 and N4. Footnote: If you are going to have multiple destination in one PO, you will need to look into the SDQ segment. Barry Rogen Senior Programmer/Analyst PNY Technologies, Inc. (973) 560-5327 bro...@pny.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [mildly ot] - EDI and drop shipments
Are you setting up specifications or do you already have a set that you're working from? You should be able to isolate the N1 loops from each other within a dataset so that each loop is a functional subset. Then, based on the BT/ST code determine what kind of information you have and apply it accordingly to you generating sales order process. The issue you are going to struggle with is going to be the unknown code (phone number) to your system. You probably won't have a customer master records to link to. At least this is one of the issues we're struggling against currently in our efforts to do this. The direction we're going is our sales orders have the extra fields for an actual third-party name and address that is a manual entry on our screens. They are not tied to the customer master file. Our documents and labels that will need to use this third-party address will have to be set so if it exists, it uses it, otherwise it will use the normal ship-to information. For the drop ship orders, the ship-to will have to default to one of the partners normal ship-to's, just to be safe and ensure the shipment never gets lost. Oh, and there really isn't a way to do drop shipments using the SDQ segment unless you have a matching ID of each SDQ CODE/QTY pairing already in your customer master file. At least not without redefining industry standards of the EDI format. I guess/assume you're using the VICS standard. This is a big monster of a change so if you want to talk concepts, we could take this off-list. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of George Gallen Sent: Friday, February 10, 2012 1:07 PM To: U2 Users Subject: [U2] [mildly ot] - EDI and drop shipments For those EDIers on the list. Do any of you process drop shipments using EDI for 850's? What method do you use? We were thinking : First N1 loop - N1 segment contains the BT and use the SAN (15 code) Second N1 loop - N1 segment contains the ST but use phone# for identification (12 code) N2 segment for Drop Ship Name N3 Segment(s) for Drop Ship Address (2 lines per N3 segment) - maximum 2 N3's N4 Segment for Drop Ship City, State, Zip and Country Currently we do not process drop shipments using EDI, and neither does this partner with any of Their other suppliers... George ___ 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] [mildly ot] - EDI and drop shipments
Aside from phone#, the other thought was just a straight text DROPSHIP, other than That, I wouldn't be relating the phone number to anything, other than a piece of data Isolating the loops isn't a problem. I have a subroutine that converts the EDI To a dynamic array, and it knows that N1 is a loop, and will create separate Them by @VM's N11,x will go with N21,x where x is the loop number. Were using customized programming, so it's not a problem to do unique things Based on the partners ID, or the a specific SAN. Thanks -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Woodward, Bob Sent: Friday, February 10, 2012 4:43 PM To: U2 Users List Subject: Re: [U2] [mildly ot] - EDI and drop shipments Are you setting up specifications or do you already have a set that you're working from? You should be able to isolate the N1 loops from each other within a dataset so that each loop is a functional subset. Then, based on the BT/ST code determine what kind of information you have and apply it accordingly to you generating sales order process. The issue you are going to struggle with is going to be the unknown code (phone number) to your system. You probably won't have a customer master records to link to. At least this is one of the issues we're struggling against currently in our efforts to do this. The direction we're going is our sales orders have the extra fields for an actual third-party name and address that is a manual entry on our screens. They are not tied to the customer master file. Our documents and labels that will need to use this third-party address will have to be set so if it exists, it uses it, otherwise it will use the normal ship-to information. For the drop ship orders, the ship-to will have to default to one of the partners normal ship-to's, just to be safe and ensure the shipment never gets lost. Oh, and there really isn't a way to do drop shipments using the SDQ segment unless you have a matching ID of each SDQ CODE/QTY pairing already in your customer master file. At least not without redefining industry standards of the EDI format. I guess/assume you're using the VICS standard. This is a big monster of a change so if you want to talk concepts, we could take this off-list. BobW ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [mildly ot] - EDI and drop shipments
Without seeing your approach to handling your data, and more importantly how you're feeding this data into your sales order system, I'm not real sure what you're asking for. The only thing I really see in your original question is about recognizing what the data in the N1 loop is. That's what the BT and ST are for. Your approach of how you keep track of the data inside your program is going to be based on the way you think. Myself, I like more descriptive variables like BILLTO.ID and SHIPTO.NAME kind of things. Don't know if I'm clearing the water or stomping in the mud but I hope it helps. Good luck. BobW -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of George Gallen Sent: Friday, February 10, 2012 1:51 PM To: U2 Users List Subject: Re: [U2] [mildly ot] - EDI and drop shipments Aside from phone#, the other thought was just a straight text DROPSHIP, other than That, I wouldn't be relating the phone number to anything, other than a piece of data Isolating the loops isn't a problem. I have a subroutine that converts the EDI To a dynamic array, and it knows that N1 is a loop, and will create separate Them by @VM's N11,x will go with N21,x where x is the loop number. Were using customized programming, so it's not a problem to do unique things Based on the partners ID, or the a specific SAN. Thanks -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Woodward, Bob Sent: Friday, February 10, 2012 4:43 PM To: U2 Users List Subject: Re: [U2] [mildly ot] - EDI and drop shipments Are you setting up specifications or do you already have a set that you're working from? You should be able to isolate the N1 loops from each other within a dataset so that each loop is a functional subset. Then, based on the BT/ST code determine what kind of information you have and apply it accordingly to you generating sales order process. The issue you are going to struggle with is going to be the unknown code (phone number) to your system. You probably won't have a customer master records to link to. At least this is one of the issues we're struggling against currently in our efforts to do this. The direction we're going is our sales orders have the extra fields for an actual third-party name and address that is a manual entry on our screens. They are not tied to the customer master file. Our documents and labels that will need to use this third-party address will have to be set so if it exists, it uses it, otherwise it will use the normal ship-to information. For the drop ship orders, the ship-to will have to default to one of the partners normal ship-to's, just to be safe and ensure the shipment never gets lost. Oh, and there really isn't a way to do drop shipments using the SDQ segment unless you have a matching ID of each SDQ CODE/QTY pairing already in your customer master file. At least not without redefining industry standards of the EDI format. I guess/assume you're using the VICS standard. This is a big monster of a change so if you want to talk concepts, we could take this off-list. BobW ___ 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] [mildly ot] - EDI and drop shipments
George, EDI is more people-oriented than technical. The X12 documents provide a structure, and trading partners can discuss the content used to populate those structures to achieve their business goals. There are few details about the 850, 856, 820, 997, 810, etc that can't be negotiated to accommodate specific business practices. Every discussion with a different partner will yield different results, though your inquiry here may give you more ideas to bring to the table, and can help to establish standards among partners. It's been my experience that more time is spent on the phone, in emails, and in the conference room than in code when it comes to EDI. Getting the agreements documented up front saves huge amounts of coding and retrofitting on the back-end. So I encourage you to take the feedback you get here and bring it to your trading partners to see if it works for them - and ask them if they have ideas about how they have already done this or how they see it happening. That partnership toward a common goal (again, very people-oriented) will really help to make this technical initiative work for everyone. HTH T Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com remove.pleaseNebula-RnD.com/blog Visit http://PickWiki.com! Contribute! http://Twitter.com/TonyGravagno NEW! http://groups.google.com/group/mvdbms/about From:George Gallen For those EDIers on the list. Do any of you process drop shipments using EDI for 850's? What method do you use? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] universe compiler -xref output
The universe compiler (-xref) option is pretty useful for tracking down variable usage. Specifically, I'd like to eliminate assigned but unused variables, so I'm looking for output that has single assignments only. It looks like the raw compiler output from -X is from an intermediate file and then captured using retrieve. Does anyone know if the intermediate file is available for running my own reports? On d3 it was the BSYM file and you could write your own reports to find what you need. I'm looking for something similar on universe because scanning for these variable assignments from large programs is very tedious using the current data in the captured cross reference listing that comes out of the source.L file. Worst case, I guess I could write another program to scan that record for what I need. -Troy _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [mildly ot] - EDI and drop shipments
Tony, I can't agree more, as I've always said, EDI standards are the most non-standard things I've ever seen. Problem is I hadn't ever worked with drop shipments in EDI, and the trading partner we are trying to do this with has never done using EDI either, and I probably know more about EDI than they do, and I barely have scratched the surface of it, so as you said, we will need to bring to the table the ideas and come to an agreement. Seems that my thought patten for how to address the drop shipment in the transactions seems to be on target with the responses have been, so that's a good sign. But since I'm doing custom software that more depends on what the other side is sending, and what the other side needs, it's really difficult when the other side doesn't know what they need! Yes, we could just come up with a protocol that is good for us, but I really wanted to make sure what we come up with is workable for other partners without much tweeking. George Gallen Senior Programmer/Analyst Accounting/Data Division ggal...@wyanokegroup.com ph:856.848.9005 Ext 220 The Wyanoke Group http://www.wyanokegroup.com From: u2-users-boun...@listserver.u2ug.org [u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno [3xk547...@sneakemail.com] Sent: Friday, February 10, 2012 6:47 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [mildly ot] - EDI and drop shipments It's been my experience that more time is spent on the phone, in emails, and in the conference room than in code when it comes to EDI. Getting the agreements documented up front saves huge amounts of coding and retrofitting on the back-end. So I encourage you to take the feedback you get here and bring it to your trading partners to see if it works for them - and ask them if they have ideas about how they have already done this or how they see it happening. That partnership toward a common goal (again, very people-oriented) will really help to make this technical initiative work for everyone. HTH T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [mildly ot] - EDI and drop shipments
George, May I suggest that you also post this question to the EDI-L group at: ed...@yahoogroups.com? They are all EDI specialists, much like most of us are U2/multivalue specialists. I'll look for your question on the EDI-L list and I look forward to the responses you get. Best regards, Dave Taylor Sysmark Information Systems, Inc. www.sysmarkinfo.com On 10.02.2012 17:55, George Gallen wrote: Tony, I can't agree more, as I've always said, EDI standards are the most non-standard things I've ever seen. Problem is I hadn't ever worked with drop shipments in EDI, and the trading partner we are trying to do this with has never done using EDI either, and I probably know more about EDI than they do, and I barely have scratched the surface of it, so as you said, we will need to bring to the table the ideas and come to an agreement. Seems that my thought patten for how to address the drop shipment in the transactions seems to be on target with the responses have been, so that's a good sign. But since I'm doing custom software that more depends on what the other side is sending, and what the other side needs, it's really difficult when the other side doesn't know what they need! Yes, we could just come up with a protocol that is good for us, but I really wanted to make sure what we come up with is workable for other partners without much tweeking. George Gallen Senior Programmer/Analyst Accounting/Data Division ggal...@wyanokegroup.com ph:856.848.9005 Ext 220 The Wyanoke Group http://www.wyanokegroup.com From: u2-users-boun...@listserver.u2ug.org [u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno [3xk547...@sneakemail.com] Sent: Friday, February 10, 2012 6:47 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [mildly ot] - EDI and drop shipments It's been my experience that more time is spent on the phone, in emails, and in the conference room than in code when it comes to EDI. Getting the agreements documented up front saves huge amounts of coding and retrofitting on the back-end. So I encourage you to take the feedback you get here and bring it to your trading partners to see if it works for them - and ask them if they have ideas about how they have already done this or how they see it happening. That partnership toward a common goal (again, very people-oriented) will really help to make this technical initiative work for everyone. HTH T ___ 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
