开云体育

I have up and running MVS38j and VM370 6PExt and appear to be working
correctly.? Next I want to connect VM370 to MVS38j so the VM370 system
could send jobs and get prints back.

I have studied the NJE38 manual, but it only shows MVS TO MVS.

I have configured both NJE38 and VM370 for my configuration( node names, ports etc)
When I bring up NJE38 on MVS, it stats waiting for connection.? I start the
RSCS on VM370 and it connects to MVS and on both systems, it shows the line
connected.? I get a BPbuffer size request sent from MVS to VM370 and that appears
to be good.? However I can not pass any traffic in either direction.? So I guess I missed
something, but I can not find any hints in any documentation.

Anyone tried and made this type of connection??

Thank You
Tom c

_._,_._,_

We ran a Hasp workstation.? Not sure if there's an equivalent, or the tool referenced in the later NJ38 is equal or superior.

You would have to couple a comms channel (270x sync of some sort) between the machines, and compile the Hasp workstation to run as a VM guest.

I'd like to do that, as our data center had the Hasp workstation on a 360/50 under MVT21 submitting and receiving jobs, print and punch from the other universities VS/1 on a 370/148.? We could still submit jobs for the Watfiv system, and also jobs for local MVT.

We ran Watfiv for Fortran classes and it was run with special initiator for the system thru HASP.

Anyway, hope you will share back what you end up with.

thanks
Jim

I have up and running MVS38j and VM370 6PExt and appear to be working
correctly.? Next I want to connect VM370 to MVS38j so the VM370 system
could send jobs and get prints back.

I have studied the NJE38 manual, but it only shows MVS TO MVS.

I have configured both NJE38 and VM370 for my configuration( node names, ports etc)
When I bring up NJE38 on MVS, it stats waiting for connection.? I start the
RSCS on VM370 and it connects to MVS and on both systems, it shows the line
connected.? I get a BPbuffer size request sent from MVS to VM370 and that appears
to be good.? However I can not pass any traffic in either direction.? So I guess I missed
something, but I can not find any hints in any documentation.

Anyone tried and made this type of connection??

Thank You
Tom c

I am trying to connect MVS38j via nje38 to VM370 via RSCS.? No joy.

Has any be able to do this and if so any tips.

thank
/tc

On Sun, Jul 31, 2022 at 03:25 AM, Patrik Schindler wrote:

Am 31.07.2022 um 02:23 schrieb Drew Derbyshire <swhobbit@...>:

None of these date comments apply to the original post; as shown at the beginning of the thread, LDCODAY explicitly spells out both the Day of the Week and the Month to reduce operator errors.

I feel the discussion deteriorated somewhat to gentle teasing having left the occasional digression discussions sometimes take. Maybe don't be too serious about that. ;-)

The point I was trying make in my last comment (and in general) is that native MVS date processing is "in character" for it — in other words, utterly unfriendly!? :-)

This conversation wandered off the reservation a LONG time ago. It's hard to be serious about MVS 3.8 in general, it often feels closer to OS/MVT w/HASP II than to MVS/SP 370 (and beyond) with NJE and TCP/IP.

-ahd-

p.s. Personally, during my IBM era (thru ~1997), I made the most money working on networked MVS/ESA, networking ES/9000 to a Thinking Machines CM5 [ranked in the top 10 in the world at the time] for American Express ...? from two time zones away. I mostly did my work via a VM/ESA machine from an OS/2 desktop.? (I liked XEDIT, and at the time KEDIT, far more than ISPF.)??

(The OS/2 was in part because desktop IT refused to touch it, which is how I wanted it.)

Both TMC and the vendor of the custom network hardware we used went bankrupt on us. For round two we went pure IBM.

Hello Drew,

Am 31.07.2022 um 02:23 schrieb Drew Derbyshire <swhobbit@...>:

None of these date comments apply to the original post; as shown at the beginning of the thread, LDCODAY explicitly spells out both the Day of the Week and the Month to reduce operator errors.

I feel the discussion deteriorated somewhat to gentle teasing having left the occasional digression discussions sometimes take. Maybe don't be too serious about that. ;-)

:wq! PoC

I sometimes use the yyyy-mm-dd, for example that is my external date stamp for MVS hardcopy log.??

None of these date comments apply to the original post; as shown at the beginning of the thread, LDCODAY explicitly spells out both the Day of the Week and the Month to reduce operator errors.

-ahd-

Marco Antoniotti wrote:

[...]

Just to make it more interesting, many years ago, I switched
to "Japanese" date formats (I don't know whether they are
actually Japanese, but I remember reading so somewhere), that
is YYYYMMDD. They sort very well well.

The international (world over) standard (or at least it's SUPPOSED to be!) is ISO 8601, which is indeed YYYY-MM-DD, was chosen for precisely that reason: easy sorting:

*

I've been personally using that format for many, many years now.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...

There is a international standard for such matters when run on *.nix and Windows.

Now I have forgotten exactly for Windows but for Linux it is the Locate defaults set for the system in use and here for me and in the UK it is :

--
LANG=en_GB.UTF-8
LANGUAGE=en_GB
LC_ADDRESS=en_GB.UTF-8
LC_COLLATE=en_GB.UTF-8
LC_CTYPE=en_GB.UTF-8
LC_IDENTIFICATION=en_GB.UTF-8
LC_MEASUREMENT=en_GB.UTF-8
LC_MESSAGES=en_GB.UTF-8
LC_MONETARY=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
LC_NUMERIC=en_GB.UTF-8
LC_PAPER=en_GB.UTF-8
LC_SOURCED=1
LC_TELEPHONE=en_GB.UTF-8
LC_TIME=en_GB.UTF-8
--

Many of these are hardly original, but you should get the point.

Many of my programs that need such written? in Cobol have the following

In working storage:

*>
?01? WS-Locale?????????????????????????? pic x(16)???? value spaces.
?01? WS-Local-Time-Zone????????????????? pic 9???????? value 3.
*>
*> Sets WS-Local-Time-Zone ^~^ to one of these 88 value's according to your local requirements
*> NOTE Environment var. LC_TIME is checked for "en_GB" for UK (1) and "en_US" for USA (2)
*>?? at start of program. For any other, you can add yours if different but let the author know,
*>???? so it can be added to the master sources
*>
*>??? Note that 'implies' does NOT mean the program does anything e.g., changes page sizing in the report.
*>
???? 88? LTZ-Unix????????????????????????????????????? value 3.
???? 88? LTZ-USA?????????????????????????????????????? value 2.
???? 88? LTZ-UK??????????????????????????????????????? value 1.


In procedure division it is :

???? accept?? WS-Locale???? from Environment "LC_TIME".
???? if?????? WS-Locale (1:5) = "en_GB"
????????????? set LTZ-UK? to true
???? else if? WS-Locale (1:5) = "en_US"
????????????? set LTZ-USA to true
???? end-if.


Where the date needs to be processed and usually for reports/printing etc I just do a if test on
WS-Local-Time-Zone?? for the values 1, 2 and 3 (as default) and change the formatting accordingly.

The above form of coding is also used for other Languages one way or another.
I like to keep to the KISS principal as much as possible as it has served well over the last 60 years of programming, testing, management et al.
The kit has changed but not much else really.

Mainframe is a similar nature but not the same, as it takes the settings from within the O/S as set by a sysadmin and it is the same for all users but say for Linux can be changed for individual users for specific purposes while running an application after which it goes back to the site default.

The only light relief is with time as then it depends on, if I am using Local time or GMT, i.e., aviation applications use GMT for all and say accounting and most others? it is all Local.

Again for m/f's, this setting is totally down to the site and often is local BUT if it is an international company where the data is moved between countries it is usually GMT - This can be different for some businesses depending on requirements, so not a totally hard and fast rule.

Note the same applies to sites using micro based systems.


Hope it helps and if I am trying to teach you to suck eggs, just ignore this missive.

Vince

Hello Vince

Am 30.07.2022 um 14:44 schrieb Vince Coen <vbcoen@...>:

In that case they use the *nix standard in place of the other two standards namely :

DD/MM/CCYY - UK and many others

At least in Germany, it's not / but . as separator. This is most helpful to know if 10/12/1999 was meant as 10th of December, or 12th of October. Ambiguities are very bad. A while ago I stumbled upon a German (!) website using / as separator but DD.MM.YYYY format. Grr.

CCYY/MM/DD - Every where else but is used in some EU areas in place of the UK format.

It's getting more and more common in Germany also, with - as separator, though.

I wonder if/when anyone will come up with YYYY/DD/MM to complete the confusion. :-)

:wq! PoC

In that case they use the *nix standard in place of the other two standards namely :

DD/MM/CCYY??? - UK and many others
MM/DD/CCYY??? - USA
CCYY/MM/DD?? -? Every where else but is used in some EU areas in place of the UK format.

Almost all default to 24 hour clocks and these date back to m/f's of the 60's such as IBM 1401, 7094?? and ICL (ex ICT) 1900 to name a few although possibly also Honeywell, Burroughs, Sperry, Univax DEC etc and for these I have forgotten.

What do you want, it was 50 - 60 years ago :)

Vince

On 30/07/2022 4:54 pm, Marco Antoniotti wrote:

I switched to "Japanese" date formats

The Fujitsu assembler had an &SYSDATE format of YY.MM.DD which I found much less confusing than the &SYSDATE of IBM assemblers...

Cheers,
Greg

Hi

interesting conversation.

Just to make it more interesting, many years ago, I switched to "Japanese" date formats (I don't know whether they are actually Japanese, but I remember reading so somewhere), that is YYYYMMDD.? They sort very well well.

Cheers

--
Marco Antoniotti
Somewhere over the rainbow, going to Hell

I think we have seriously digressed here, but? marching onward ...

On Thu, Jul 28, 2022 at 04:45:43PM -0700, Drew Derbyshire wrote:

Coz they is American :)

Quite succinct and true.

Why would I use 24 hour times? That, like the Julian date, gives me a chance to blow a conversion.

I'm American, and have been using 24 hour time for a few decades. I've
worked with several systems that required entering times in 24 hour format.
Once I got used to it, it made more sense to me than "that quaint A.M. P.M.
thing" most Americans use. :-)

I even worked at one place with an employee timekeeping system in which
times had to be entered in 24 hour and fraction of an hour format. So 3:15
P.M. had to be entered as 15.25.



--

Kevin


Bruceville, TX

What's the definition of a legacy system? One that works!
Errare humanum est, ignoscere caninum.

The MVS Time SVC not only converts from timer units to hundredths of seconds, it then converts binary to packed decimal.

I finally put a loop in the code:

* Get both times

* Compare hundredths of seconds of each (GMT always seems to lag).

* If the local time fraction is lower than the GMT time fraction (local time has gone to next second) …

* … Then delay 00.05 seconds and try again.

An ugly hack which seems to work.??

>?Coz they is American :)

Quite succinct and true.

Why would I use 24 hour times? That, like the Julian date, gives me a chance to blow a conversion.

-ahd-

Coz they is American :)

--
- IMPORTANT –

This email and the information in it may be confidential, legally
privileged and/or protected by law.
It is intended solely for the use of the person to whom it is addressed.
If you are not the intended recipient, please notify the sender
immediately and do not disclose the contents to any other person, use it
for any purpose, or store or copy the information in any medium. Please
also delete all copies of this email & any attachments from your systems.

If this is an encrypted email, it is your responsibility to maintain the
1024 byte key system even for one-use keys. Once mail has been sent the
sending key is not kept and therefore a replacement mail cannot be resent.

We cannot guarantee the security or confidentiality of non encrypted email
communications. We do not accept any liability for losses or damages that
you may suffer as a result of your receipt of this email including but
not limited to computer service or system failure, access delays or
interruption, data non-delivery or mis-delivery, computer viruses or other
harmful components.

Copyright in this email and any attachments belongs to Applewood Computers.
Should you communicate with anyone at Applewood Computers by email,
you consent to us monitoring and reading any such correspondence.

Nothing in this email shall be taken or read as suggesting, proposing or
relating to any agreement concerted practice or other practice that could
infringe UK competition legislation (unless it is against Security
requirements).

This Email and its attachments (if any) are scanned for virii using
Clamd and ClamAV 0.103.5 and later (Linux x64) and others on IBM mainframe
systems.

Dykegrove Limited T/A Applewood Computers is a company registered in
England (no. 01681349) whose registered office is at Applewood House,
17 Stag Green Avenue, Hatfield, Hertfordshire, AL9 5EB

--

开云体育

A bit pf trivia ...

Long ago and far away, I worked at Link Flight Simulation of the Singer Company; we ran MVS/SP on an IBM 4341. There, on the week of 8 June 1984, an operator blew the Julian date when doing an IPL by flipping two digits. This jumped the date forward ~ 3 months and THAT caused the tape library scratch processing to have a field day and threaten to wipe out good chunk of our tape library.? (The librarians caught it promptly, thank goodness.)

I know the week because on that date I cranked out a simple program that was started immediately after IPL and displayed on the console a non-scrollable line similar to:

@LDCTODAY: Monday, 25 July 2022 (22.206)

This of course made it easy for the operator to promptly see the error of their ways.

Because I'm prone to not check the time when I IPL MVS 3.8 (after all it is slaved is to the NTP-controlled Hercules host clock except for the timezone), I recently played with the program and its underlying date routine to expand the output to report the time and timezone, and as a bonus I tossed in a second message with the GMT date and time:

@LDCTODAY: Monday, 25 July 2022 (22.206)? 9:36:19 AM -0700
@ Monday, 25 July 2022 (22.206)? 4:36:18 PM GMT

The times sources are generated by the OS TIME macro invoked twice back-to-back:

???????? TIME? DEC,ZONE=LT???????? Get current local time ...??????? ?
???? ST??? R0,LCLTIME??????????????????????????????????????????? ?
???? ST??? R1,LCLDATE??????????????????????????????????????????? ?
???? SPACE 1???????????????????????????????????????????????????? ?
???? TIME? DEC,ZONE=GMT??????? ... also get current GMT time ... ?
???? ST??? R0,GMTTIME??????????????????????????????????????????? ?
???? ST??? R1,GMTDATE????

Now knowing you did not look closely at the program output, back up and look at it carefully.

Like how time flows backwards?? My uninformed guess is a truncate issue deep in MVS with the conversion from timer units to seconds*100 and then the hundredths are dropped.

(My time working in RBOC class voice mail has taught me well: NO lossy conversion goes unpunished.)

-ahd-

-- 
Drew Derbyshire

AAAAAA - American Association Against Acronym Abuse Anonymous.